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Description 

Field of the Invention 

[0001] This invention relates to a data storage sub- 5 
system which uses a snapshot copy process to copy a 
data file by duplicating the data file pointer in a mapping 
table to reference the original data file, such that the 
name used to identify the original data file and the name 
used to identify the copied data file are both mapped to 10 
the same physical data storage location. The integrity 
of the mapping table is maintained by the use of a re- 
dundantly stored two level mapping table which enables 
a data file to be relocated with only a simple change to 
a single entry in the mapping table, even when there are ts 
multiple data file names which refer to the data file. 

Problem 

[0002] It is a problem in computer systems and data 20 
storage subsystems to perform the data file copy oper- 
ation in a manner that minimizes the use of processing 
resources and data storage space in memory. In the 
past, data files were copied in their entirety by the proc- 
essor, such that two exact copies of the selected data 25 
file were resident in memory. This operation consumed 
twice the amount of memory for the storage of two iden- 
tical copies of the data file and also required the inter- 
vention of the processor to effect the copy of the original 
data file. 30 
[0003] An improvement over this copy process was 
the data file snapshot copy process disclosed in U.S. 
Patent No. 5,410,667, wherein a dynamically mapped 
virtual data storage subsystem stored data files re- 
ceived from a processor in backend data storage devic- 35 
es by mapping the processor assigned data file identifier 
to a logical address that identifies the physical storage 
location of the data. This dynamically mapped virtual da- 
ta storage subsystem performed a copy of a data file by 
simply creating a duplicate data file pointer in a data file *o 
identifier in a mapping table to reference the original da- 
ta file. In this dynamically mapped virtual data storage 
subsystem, the data files are referred to as virtual tracks 
and each data file is identified by a unique Virtual Track 
Address. The use of a mapping table provides the op- 45 
portunity to replace the process of copying the entirety 
of a data file in the data storage devices with a process 
that manipulates the contents of the mapping table. A 
data file appears to have been copied if the name used 
to identify the original data file and the name used to so 
identify the copy data file are both mapped to the same 
physical data storage location. This enables the proc- 
essor to access the data file via two virtual track ad- 
dresses while only a single physical copy of the data file 
resides on the backend data storage devices in the data 55 
storage subsystem. This process minimizes the time re- 
quired to execute the copy operation and the amount of 
memory used since the copy operation is carried out by 



creating a new pointer to the original data file and does 
not require any copying of the data file itself. 
[0004] A problem with this copy system is that only 
the inf ormation stored in the mapping table identifies the 
fact that the data file has been copied. If the mapping 
table is lost or its contents corrupted, the effect of the 
data file copy operation is lost. This problem can be 
avoided if the data storage subsystem stores the data 
file copy information in the data file itself to thereby rep- 
licate the mapping table data. However, such a process 
requires that the original data file be updated to reflect 
each copy operation that is executed and this overhead 
reduces the benefit of the pointer manipulation. Further- 
more, any updates or changes to a data file in a log 
structured file system results in the entirety of the data 
file being rewritten in memory. Therefore, a log struc- 
tured file system does not benefit from this replication 
of the mapping data. 

[0005] A further problem with this copy system is that 
the process of updating mapping table pointers to em- 
ulate the copying of data files requires a finite amount 
of processing time. It is therefore desirable for the proc- 
essor to execute read and write operations during the 
process of updating the mapping table pointers, and this 
interleaved copy operation is termed an incremental 
copy process. This interleaving of operations can create 
instances in which the original data file (source area) is 
being written or the copy data file (target area) is being 
read or written before the mapping table update is com- 
pleted. In this instance, data written to the original data 
file before the completion of the mapping table updates 
may or may not be reflected in the copy data file. The 
copy data file also now occupies its own unique physical 
space in memory (target area) since it does not corre- 
spond to the original data file. Similarly, data read from 
the copy data file before the completion of the mapping 
table updates may be the data file being copied or the 
data file which was stored in the target area before the 
copy operation was initiated. Furthermore, data written 
to the copy data file before the completion of the map- 
ping table updates may or may not be overwritten by the 
data file being copied. This results in uncertainty with 
regard to the correspondence between the original data 
file, its modified version and the copy data file. This in- 
cremental copy process is therefore less desirable than 
a point in time copy process where the identity between 
the original and copy data files is ensured. With a point 
in time copy process, all data written to the copy source 
area before the initiation of the copy operation will ap- 
pear in the copy target area, all data written to the copy 
target area before the initiation of the copy will be over- 
written by data from the copy source area, no data writ- 
ten to thecopy source area afterthe initiation of the copy 
will appear in the copy target area and no data written 
to the copy target area after the initiation of the copy 
process will be overwritten by data from the copy source 
area. It is therefore desirable to provide an incremental 
copy process which interleaves read and write opera- 
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tions with the mapping table updates, but also preserves 
the point in time snapshot copy semantics to ensure cor- 
respondence of the copy and original data files during 
the mapping table updates. 

[0006] Another problem with the incremental copy s 
process is that this process can bypass security policies 
that block unauthorized data access. For example, a 
certain group of users may have access to a data file 
that was previously stored in the memory location now 
used for the copy data file. These users can access the io 
copy data file that is being written to this area as part of 
the incremental copy process if the mapping table point- 
ers, with its file access permissions, has not yet been 
updated. Thus, the access permission process is not 
synchronized with the copy process and users can ac- is 
cess files for which they are not authorized. 
[0007] Thus, there presently is no snapshot copy 
process available that both efficiently ensures the relia- 
bility of the mapping table data and also performs an 
incremental copy process which preserves the point in 20 
time copy semantics to ensure copy data file corre- 
spondence to the original data file. 

Solution 

25 

[0008] The above described problems are solved and 
a technical advance achieved by the present data file 
storage management system for snapshot copy opera- 
tions. This system maintains a two level mapping table 
which enables the data files to be copied using the snap- 30 
shot copy process but only requires the update of a sin- 
gle corresponding mapping table entry when the phys- 
ical location of the data file instance is changed. The 
snapshot copy updates to the contents of the first level 
of the two level mapping table are stored on the backend 35 
data storage devices to provide a record of the snapshot 
copy operation which can be used to recover the correct 
contents of the mapping table. This record of the snap- 
shot copy operation remains valid even though the 
physical location of a copied data file instance is subse- 40 
quently changed. Furthermore, the physical storage 
space holding the updated portions of the first level of 
the two level mapping table can be managed using tech- 
niques like those used to manage the physical storage 
space holding data file instances. In addition, the syn- *s 
chronization of the snapshot copy operation with the 
reading and writing of data to the original and copy data 
files is maintained by detecting accesses to the original 
data file or the copy file during the time that the snapshot 
copy process is being executed and the mapping table so 
is being updated. Mapping table updates resulting from 
the snapshot copy operation are delayed until all map- 
ping table updates resulting from earlier data file write 
operations have been completed and any attempt to up- 
date the mapping table to reflect data written to the orig- ss 
inal data file or the copy data file that occurs after initi- 
ation of the snapshot copy operation must wait until the 
first set of mapping table pointers have been updated. 



[0009] The present data file storage management 
system for snapshot copy operations is implemented in 
a dynamically mapped virtual data storage subsystem 
to maintain data file copy integrity in snapshot copy op- 
erations. The data storage subsystem is connected to 
at least one processor and functions to store data files 
for the processor in the backend data storage devices 
that are part of the data storage subsystem. The proc- 
essor assigns a virtual track address to a data file which 
is transmitted to the data storage subsystem for storage 
in an allocated physical storage location in the backend 
data storage devices. The assignment of a physical stor- 
age location on the backend data storage devices is ef- 
fected by a controller contained within the data storage 
subsystem, which defines the correspondence between 
the processor assigned virtual track address and the 
logical address of the stored data file. A mapping table 
translates the virtual track address into a logical address 
which identifies the location of the data file on a physical 
disk drive. The location of the data file changes as the 
data storage subsystem free space collection process 
moves the data file to create free space into which new 
data can be written, ft is therefore insufficient to store 
the translation from a virtual address to a logical address 
as a means of preserving a record of the mapping table 
updates, since the free space collection process chang- 
es the physical location of the data file but does not up- 
date these translations. The data files stored on the disk 
drives must therefore contain information that is inde- 
pendent of the logical address at which the data file 
presently being copied is stored. This enables the disk 
stored information to remain valid even thought the 
physical location of the data file may change over time. 
This is accomplished by the use of a two level mapping 
architecture. The first level of mapping tables maps a 
virtual address to an immutable name which identifies 
a unit of data, such as a virtual track. The second level 
of mapping maps the immutable name to a given logical 
address. The snapshot copy operation operates on the 
first level of the mapping table to create multiple copies 
of the virtual track, thereby eliminating the need to as- 
sociate with each virtual track address a mapping table 
entry which contains a logical address. 
[0010] In a snapshot copy operation, to provide the 
illusion of there being two independent copies of the da- 
ta, any write to one of the copies must leave the other 
copy unchanged. In a log structured file system, the writ- 
ing of data or changes to a data file results in the data 
file being written to a different location in memory. If the 
original data file is accessible by a plurality of virtual ad- 
dresses, it must remain in its original form for access by 
the remaining users, while the changes to this data file 
must be reflected in a new copy of the data file which 
incorporates these changes. The mapping table must 
therefore be updated in such a manner that the virtual 
address to the new data file points to this new copy of 
the data file, while the remaining virtual addresses point 
of the original data file location. 
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[001 1] The problem of providing point in time copy se- 
mantics for the snapshot copy operation is solved by 
completing data file accesses that are already in 
progress before initiating the mapping table updates 
performed by the snapshot copy process and detecting 
accesses to the original data file or the copy file during 
the time that the snapshot copy process is being exe- 
cuted and the mapping table is being updated. The map- 
ping table updates performed by the snapshot copy 
process are delayed until the completion of the data file 
accesses that preceded the command that initiated the 
snapshot copy process and any attempt to update the 
mapping table to reflect data written to the original data 
file or the copy data file that occurs after initiation of the 
snapshot copy process must wait until the first set of 
mapping table pointers have been updated. This en- 
sures that the data file access operations behave as 
though data file access operations initiated before the 
snapshot copy operation were completed before the in- 
itiation of the snapshot copy operation and all data file 
access operations initiated after the initiation of the 
snapshot copy operation were initiated after the com- 
pletion of the snapshot copy operation. The use of afautt 
tolerant cache allows this write delay to be hidden from 
the processor. Any request to read data from the copy 
data file received before the mapping table pointers 
have been updated is redirected to the original data file 
to ensure that the data file read operation behaves as 
though the snapshot copy process had been completed. 
[0012] Thus, the present data file storage manage- 
ment system for snapshot copy operations both effi- 
ciently ensures the reliability of the mapping table data 
and also performs an incremental copy process which 
preserves the point in time copy semantics to ensure 
copy data file correspondence to the original data file. 

Brief Description of the Drawing 

[0013] 

Figure 1 illustrates in block diagram form the archi- 
tecture of a typical data storage subsystem in which 
the present data file storage management system 
for snapshot copy operations is implemented; 
Figure 2 illustrates in block diagram form the imple- 
mentation of the two level mapping table as a Virtual 
Track Table and a Track Number Table; 
Figure 3 illustrates in block diagram form a typical 
implementation of a Logical Cylinder; 
Figure 4 illustrates in block diagram form a Logical 
Cylinder Directory entry which describes a Virtual 
Track Instance; 

Figure 5 illustrates in block diagram form a Logical 
Cylinder Directory entry which describes a Virtual 
Track Table Page Instance; 
Figures 6A - 6B illustrate in flow diagram form the 
operational steps taken by the controller to perform 
a snapshot copy process; 



Rgures 7A - 7B illustrate in flow diagram form the 
operational steps taken by the controller to carry out 
the free space collection process; 
Figures 8-13 illustrate in block diagram form the 
5 state of the mapping table at various stages of a 
snapshot copy operation; 
Figure 14 illustrates in flow diagram form the oper- 
ational steps taken by the controller when screening 
data file read requests; 
10 Figure 1 5 illustrates in flow diagram form the oper- 
ational steps taken bythecontrollerwhen screening 
virtual track write requests; and 
Figures 1 6A - 1 6C illustrate in flow diagram form the 
operational steps taken by the present data file stor- 
es age management system for snapshot copy opera- 
tions to store a received data file and create copies 
thereof. 

Detailed Description 

20 

[0014] The present data file storage management 
system for snapshot copy operations maintains a two 
level mapping table which enables the data files to be 
copied using the snapshot copy process but only re- 

25 quires the update of a single corresponding mapping ta- 
ble entry when the physical location of the data file in- 
stance is changed. The snapshot copy updates to the 
contents of the first level of the two level mapping table 
are stored on the backend data storage devices to pro- 

so vide a record of the snapshot copy operation which can 
be used to recover the correct contents of the mapping 
table. This record of the snapshot copy operation re- 
mains valid even though the physical location of a cop- 
ied data file instance is subsequently changed. Further- 

35 more, the physical storage space holding the updated 
portions of the first level of the two level mapping table 
can be managed using techniques like those used to 
manage the physical storage space holding data file in- 
stances. At least one of these two mapping tables are 

40 stored on the backend data storage devices to provide 
a backup of the mapping data that is stored in the virtual 
track directory. In addition, the synchronization of the 
snapshot copy operation with the reading and writing of 
data to the original and copy data files is maintained by 

45 detecting accesses to the original data file or the copy 
file during the time that the snapshot copy process is 
being executed and the mapping table is being updated. 
Mapping table updates resulting from the snapshot copy 
operation are delayed until all mapping table updates 

so resulting from earlier data file write operations have 
been completed and any attempt to update the mapping 
table to reflect data written to the original data file or the 
copy data file that occurs after initiation of the snapshot 
copy operation must wait until the first set of mapping 

55 table pointers have been updated. 



4 



7 



EP1 012 721 B1 



8 



Data Storage Subsystem Architecture 

[0015] The present data file storage management 
system for snapshot copy operations 1 06 is implement- 
ed in a dynamically mapped virtual data storage sub- 5 
system 1 00 which is connected to at least one processor 
101 and which functions to store data files for the proc- 
essor 1 01 in the backend data storage devices 1 05 that 
are part of the data storage subsystem 100. The proc- 
essor transmits a data file for storage in the data storage 10 
subsystem 1 00 over a selected one of the data channels 
1 03 which serve to interconnect the processor 1 01 with 
the data storage subsystem 1 00. The processor 1 01 as- 
signs a virtual track identification to the data file trans- 
mitted to the data storage subsystem 100 and the re- 15 
ceived data file is stored in an allocated physical storage 
location in the backend data storage devices 105 con- 
tained in the data storage subsystem 100. The assign- 
ment of a physical storage location on the backend data 
storage devices 1 05 is effected by a controller 1 04 con- 20 
tained within the data storage subsystem 1 00, which de- 
fines the correspondence between the processor 1 01 
assigned virtual track identification and the logical ad- 
dress of the stored data file. This translation of the virtual 
track identification to the logical address corresponding 25 
to the physical storage location comprises the "dynam- 
ically mapped virtual" aspect of the data storage sub- 
system 1 00. A cache memory 1 02 is included in the data 
storage subsystem 1 00 to provide temporary storage for 
data files as well as data used by the controller 1 04. The 30 
present data file storage management system for snap- 
shot copy operations 1 06 is implemented, in part, in the 
controller 104, with the exact implementation details of 
this system being a matter of engineering choice. 

35 

Snapshot Copy Process 

[001 6] The snapshot copy process 1 07 is implement- 
ed by the use of a two level mapping architecture. The 
first level of mapping maps the processor 1 01 provided 40 
virtual address to an immutable name which identifies 
a unit of data, such as a virtual track. The second level 
of mapping maps the immutable name to a given logical 
address. The snapshot copy operation operates on the 
first level of the mapping table, thereby eliminating the 45 
need to associate with each virtual track address a map- 
ping table entry which contains a logical address. The 
two mapping tables used to implement the two level* 
mapping table, as shown in Rgure 2, are the Virtual 
Track Table and the Track Number Table. The Virtual so 
Track Table is indexed using the processor 1 01 provided 
virtual track address which then provides a unique im- 
mutable name, comprising a Track Number, that is used 
as the index for the Track Number Table. The Track 
Number is valid for the life of the virtual track instance, 55 
as determined by the reference count contained in the 
Track Number Table. The reference count represents 
the number of times a virtual track instance (physical 



copy of the received data file) appears as a virtual track 
to the processor 101. 

[0017] There are three sources for updates to the Vir- 
tual Track Table: snapshot copy, data file delete, and 
normal processor 1 01 write activity. When the processor 
101 writes to an existing virtual track, the data file stor- 
age management system for snapshot copy operations 
106 must check the reference count in the Track 
Number Table entry pointed to by the Track Number as- 
sociated with that virtual track address. If the reference 
count is one, no other virtual tracks share the storage of 
the virtual track instance, therefore the new virtual track 
instance simply uses the same track number and the 
Track Number Table entry is updated to reflect the new 
logical address for this data file. The old logical address 
of the data file now contains invalid data (old virtual track 
instance) and the data storage subsystem 100 free 
space collection process eventually discards this old vir- 
tual track instance. If the processor 101 writes to a virtual 
track which has a reference count greater than one or 
writes to a track that has never been assigned a track 
number, a new track number must be assigned to the 
new virtual track instance. The data file storage man- 
agement system for snapshot copy operations 1 06 dec- 
rements the reference count for the track number origi- 
nally associated with the virtual track address (if any) to 
remove this virtual track's usage of the old virtual track 
instance. The data file storage management system for 
snapshot copy operations 1 06 then acquires an unused 
Track Number, which is assigned to the virtual track's 
address in the Virtual Track Table. There is one Track 
Number for each possible virtual track instance that is 
defined by the present virtual device configuration. If 
processor 101 instructs data storage subsystem 100 to 
delete a virtual track, data file management system for 
snapshot copy operations 106 decrements the refer- 
ence count for the track number associated with the Vir- 
tual Track Address (if any) to remove this virtual track's 
usage of the virtual track instance. Data file manage- 
ment system for snapshot copy operations 1 06 then re- 
moves the association between the Virtual Track Ad- 
dress and the Track Number which previously identified 
the virtual track instance selected by the Virtual Track 
Address. 

[001 8] The benefits of a two level mapping table are: 

1 . Snapshot copy operations are performed without 
having to write new instances of the virtual tracks 
involved in the copy. 

2. Error recovery capability of the mapping table. A 
copy is made of the mapping table Virtual Track Ta- 
ble and this data is written to the disks of the back- 
end data storage devices 105 as with other data. 
The mapping table data is thereby recoverable the 
same as virtual track instances. 

3. The number of copies of a virtual track instance 
is determined solely by the size of the reference 
count field. 
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Virtual Track Table 

[0019] Figure 2 illustrates in block diagram form the 
implementation of a two level mapping table in the 
present data file storage management system for snap- 
shot copy operations 1 06. The first level of the mapping 
table, comprising the Virtual Track Table, provides the 
mapping from the individual virtual address provided by 
the processor 101 to an immutable name which is used 
to index the corresponding entry in the second level of 
the two level mapping table. The second level of the 
mapping table, comprising the Track Number Table, pro- 
vides the mapping from the immutable name stored in 
the VirtualTrack Table to the logical address which iden- 
tifies the physical storage location in the backend data 
storage devices 105 that contains the received virtual 
track instance. 

[0020] In the example provided herein, the processor 
1 01 stores virtual tracks, which are associated with a 
virtual device, in the data storage subsystem 100. The 
Virtual Track Address, assigned by processor 1 01 to a 
virtual track, identifies a particular track by assigning the 
track a virtual cylinder number and a virtual track- ' 
number. For each virtual device defined by the proces- 
sor 1 01 , the data storage subsystem 1 00 stores a list of 
addresses which point to Virtual Track Table Pages 
(VTT Pages), each page containing a predetermined 
number (for example: 81 92) of byte segments of mem- 
ory. The physical storage for these Virtual Track Table 
Pages may be within cache memory 1 02, within control- 
ler 104, within data storage devices 105, or a combina- 
tion of these locations as a matter of engineering choice. 
[0021 ] These Virtual Track Table Pages each contain 
an entry for each virtual track within a 128 cylinder 
boundary of the virtual device. The number of Virtual 
Track Table Pages per virtual device is dependent on 
the maximum number of virtual cylinders that are de- 
fined in the virtual device's configuration. Also contained 
within each virtual Track Table Page is data which de- 
fines the Logical Address of a copy of the virtual Track 
Table Page comprising a Virtual Track Table Page in- 
stance which has been written on backend data storage 
devices 105 during the snapshot copy operation. This 
Logical Address identifies the physical storage location 
in the backend data storage devices 105 that contains 
the most recently written instance of the present Virtual 
Track Table Page. 

[0022] Each of the Virtual Track Table Pages com- 
prise a plurality of table entries, which are indexed by 
cylinder number and virtual track number within the vir- 
tual device (for example: Cyl 0, Trk 0). The table entries 
comprise a series of flags and a Track Number compris- 
ing a data entry of predetermined size, which contains 
the data required to access a corresponding entry con- 
tained in the Track Number Table. In the example pro- 
vided herein, the Track Number comprises a 28 bit entity 
which contains three segments: Track Number Partition, 
Track Number Segment Index, Track Number Suffix. 



The Track Number Partition selects a list of Track 
Number Table Page addresses. The Track Number 
Segment Index is 1 0 bits in size and is the index into the 
list of Track Number Table Page addresses for this track 

5 partition number. The Track Number Suffix Is 1 0 bits in 
size and comprises the index within the Track Number 
Table Page. The Track Number therefore comprises a 
unique identifier which points to a single entry in the 
Track Number Table, which contains data that is used 

10 to identify the physical storage location in the backend 
data storage devices 1 05 that contains the received vir- 
tual track instance. 

Track Number Table 

15 

[0023] Figure 2 also illustrates, in block diagram form, 
the implementation of a Track Number Table in the 
present data file storage management system for snap- 
shot copy operations 106. Conceptually, the Track 

20 Number Table is a linear table that maps each Track 
Number representing a virtual track instance to a logical 
address which identifies the physical storage location 
holding the virtual track instance on the backend data 
storage devices 105. In practice, the Track Number Ta- 

25 ble is organized much like the Virtual Track Table, with 
portions of the table segmented into the Track Number 
Table Pages. The Track Number Table is initially in- 
dexed with the Track Number Partition which selects a 
list of Track Number Table Page addresses. The Track 

30 Number Segment Index then selects the appropriate 
Track Number Table Page address from the list of Track 
Number Table Page addresses. A Track Number Table 
Page address points to a Track Number Table Page 
which contains a predetermined number (for example: 

35 8192) of byte segments of memory. These Track 
Number Table Pages each contain an entry for each vir- 
tual track within a 1 024 Track Number boundary. As with 
the Virtual Track Table, the physical storage for these 
Virtual Track Table may be within cache memory 102, 

40 within controller 104, within data storage devices 105, 
or a combination of these locations as a matter of engi- 
neering choice. 

[0024] A plurality of the Track Number Table Pages 
are grouped as segments of a cache buffer block, with 

45 a plurality of the cache buffer blocks being used to define 
the Track Number Table. In practice, the Track Number 
Partition identifies the one of the plurality of cache buffer 
blocks that contains the Track Number Table Page of 
interest. The Track Number Segment Index provides the 

so next layer of granularity and identifies the particular 
Track Number Table Page within this cache buffer block 
that is of interest. Finally, the Track Number Suffix de- 
fines the particular Track Number Table Page entry that 
corresponds to the requested virtual track instance 

55 stored on the backend data storage devices 1 05. 
[0025] The particular implementation of the two level 
mapping table disclosed herein represents one imple- 
mentation and other variations of this scheme can be 
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used for the same purpose. What is of note herein is 
that the Track Number represents an immutable name 
for the virtual track instance, such that the Virtual Track 
Table can be manipulated by the present data file stor- 
age management system for snapshot copy operations 
106 to perform the snapshot copy function without re- 
gard for the logical address of the virtual track instance. 
The logical address of the virtual track instance is man- 
aged such that any change in the physical storage lo- 
cation of the virtual track instance need be recorded only 
in a single location in the Track Number Table, regard- 
less of the number of virtual track addresses associated 
with the virtual track instance in the Virtual Track Table. 

Additional Data Structures 

[0026] Data storage subsystem 1 00 formats the data 
it stores on backend data storage devices 105 in a data 
structure known as a Logical Cylinder Figure 3 illus- 
trates in block diagram form a typical implementation of 
a Logical Cylinder. The Logical Cylinder consists of a 
plurality of Virtual Track Instances and/or VTT Page In- 
stances and a Logical Cylinder Directory (LCD). The 
Logical Cylinder Directory consists of s LCD entry for 
each Virtual Track Instance and/or VTT Page Instance 
in the Logical Cylinder, a count of the total number of 
LCD Entries in the LCD, a count of those LCD Entries 
which describe VTT Page Instances and a Logical Cyl- 
inder Sequence Number (LCSN). An optional pad area 
may separate the Virtual Track Instances and/or VTT 
Page Instances from the Logical Cylinder Directory so 
as to ensure that the final portion of the LCD is stored 
at the end of the regions of the backend data storage 
devices 1 05 which together are used to hold the Logical 
Cylinder. The LCD summarizes the contents of the Log- 
ical Cylinder. The Logical Cylinder Sequence Number 
can be used to determine the order in which Logical Cyl- 
inder were written, enabling the recovery of the mapping 
table by repeating the sequence of mapping table up- 
dates which took place when each logical cylinder was 
written. 

[0027] Figure 4 depicts in block diagram form an Log- 
ical Cylinder Directory entry which describes a Virtual 
Track Instance. Each Logical Cylinder Directory entry 
contains an Logical Cylinder Directory Entry Type, 
which in this case identifies the entry as being one which 
describes a Virtual track Instance. The Virtual Track Ad- 
dress field within this type of Logical Cylinder Directory 
entry contains the Virtual Track Address which proces- 
sor 1 01 initially assigned to the virtual track when it was 
most recently written or modified. If a virtual track and 
then the physical position of the virtual track instance is 
changed by the free space collection process, a NULL 
value is written into the Virtual Track Address field. This 
NULL value indicates that even though the Virtual Track 
Instance still represents the current data file associated 
with the Virtual Track Address to which the data file was 
most recently written. 



[0028] The Track Number field contains the immuta- 
ble name by which this Virtual track Instance is known. 
The Track Number contained in the Track Number field 
of this type of Logical Cylinder Directory entry is used to 
5 select the entry in the Track Number Table which con- 
tains the logical address of the Virtual Track Instance 
described by the Logical Cylinder Directory entry. 
[0029] The Logical Address and Virtual Track In- 
stance Length fields identify where in the Logical Cylin- 

10 der the Virtual Track Instance starts and ends. 

[0030] Figure 5 depicts in block diagram form a Log- 
ical Cylinder Directory entry which describes a Virtual 
Track Table Page Instance. The Logical Cylinder Direc- 
tory Entry Type identifies the Logical Cylinder Directory 

*5 entry as being one which describes a VTT Page In- 
stance. The VTT Page Identifier field identifies which 
VTT Page is contained in the Logical Cylinder. The Orig- 
inal LCSN field contains the LCSN of the Logical Cylin- 
der in which this instance of the VAT Page was first writ- 

20 ten. This will differ from the LCSN of the Logical Cylinder 
that currently contains the VTT Page Instance when the 
physical location of the VAT Page Instance has been 
changed by the free space collection process. Preserv- 
ing the LCSN of the Logical Cylinder in which the VTT 

25 Page Instance was originally written allows the recovery 
of the mapping table updates performed by a snapshot 
copy operation when the mapping table is being recov- 
ered by repeating the sequence of mapping table up- 
dates which took place when each logical cylinder was 

30 written. In the case of the mapping table updates cap- 
tured in the VTT Page Instance, the time at which the 
mapping table recovery process reads the VTT Page 
Instance into the mapping table is determined by the LC- 
SN of the logical cylinder into which the VTT Page In- 

35 stance was originally written, not the LCSN of the Log- 
ical Cylinder in which the VTT Page Instance is currently 
stored. 

[0031] Figure 6 illustrates in flow diagram form the op- 
erational steps taken by controller 1 04 to carry out snap- 

40 shot copy process 1 07 in response to processor 1 01 in- 
structing data storage subsystem 1 00 to copy one or 
more source data files for which processor 1 01 has as- 
signed one or more Virtual Track Addresses (these data 
files constituting the source area) to an equal number of 

45 target data files which are again identified by processor 
101 using one or more Virtual Track Addresses (the tar- 
get area). Host processor 1 01 has the flexibility to spec- 
ify a single source data file multiple times in its definition 
of the source area. In this fashion, processor 101 may 

so employ a single snapshot copy command issued to data 
storage subsystem 100 to direct the snapshot copy 
process 107 depicted in Figure 6 to make a plurality of 
copies of a source data file. 

[0032] At step 601 , controller 1 04 receives the identity 
55 of the copy source data files from processor 1 01 . In pre- 
ferred implementation, processor 1 04 specifies the data 
files to be copied by transmitting over data channel 1 03 
the Virtual Track Addresses of the data files (also known 
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as virtual tracks or simply tracks) to be copied. At step 
602, controller 1 04 determines whether modified forms 
of any of the source tracks are stored in cache memory 
102. if such modified source tracks are found in cache 
memory 102, processing proceeds with step 603 at 
which point controller 104 writes the modified source 
tracks to backend data storage devices 105. If proces- 
sor 1 00 had issued a command to write data to a source 
track before the initiation of the snapshot copy com- 
mand and this write command has not yet completed, 
the processor 101 initiated write to the source track is 
allowed to complete before the modified form of the 
source track is written to backend data storage devices 
105. At step 604 controller 104 updates the Track 
Number Table (TNT) by writing into the TNT entries 
which describe the virtual track instances written at step 

603 the logical addresses of the locations within back- 
end data storage devices 105 at which the modified 
track instances were stored. At the completion of step 

604 or if no modified source tracks were found in cache 
memory 1 02 at step 602, processing proceeds with step 
605. 

[0033] At step 605. controller 1 04 receives the identity 
of the copy target data files from processor 1 01 . As in 
the case of receiving the identity of the copy source data 
files, processor 1 04 transmits over data channel 1 03 the 
Virtual Track Addresses of the copy target data files. The 
copy target data files are the ones to which the copy 
source data files will appear to have been copied as 
soon as the specification of the copy target data files 
has been received by controller 104. 
[0034] At step 606, controller 1 04 determines whether 
any of the target tracks are stored in cache memory 1 02. 
If target tracks are found in cache memory 1 02, process- 
ing proceeds with step 607 at which point controller 1 04 
removes the target tracks from cache memory 102. If 
processor 1 00 had issued a command to read data from 
a target track before the initiation of the snapshot copy 
command and this read command has not yet complet- 
ed, the target track read command is allowed to com- 
plete before the target track being read is removed from 
cache memory 1 02. The target tracks removed from 
cache memory 1 02 represent the data files which proc- 
essor 101 had written into the copy target area prior to 
the initiation of the snapshot copy operation. Removing 
these target tracks from cache memory 102 ensures 
that if processor 101 reads a target data file from data 
storage subsystem 1 00 after it has transmitted the def- 
inition of the target area to storage subsystem 1 00, proc- 
essor 101 will not receive the data files which were 
stored in the target data area prior to the snapshot copy 
operation. At the completion of step 607 or if no target 
tracks were found in cache memory 102 at step 606, 
processing proceeds with step 608. 
[0035] At step 608, controller 104 chooses a Virtual 
Track Table Page which contains one or more entries 
that are selected bytarget Virtual Track Addresses. Step 
608 is the first step in a program loop consisting of steps 



608 through 61 8. Each iteration of this program loop car- 
ries out the steps required to update a Virtual Track Ta- 
ble Page and store the Virtual Track Table Page on 
backend data storage devices 1 05. 

5 [0036] At step 609, controller 104 chooses a Virtual 
Track Table entry within the currently selected Virtual 
Track Table Page which maps a target Virtual Track Ad- 
dress to a Track Number. Step 609 is the first step in a 
program loop consisting of steps 609 through 615. Each 

10 iteration of this program loop carries out the steps re- 
quired to update a Virtual Track Table entry so that the 
Virtual Track Table entry maps a target Virtual Track Ad- 
dress to the same Track Number as the Track Number 
which represents the source data file which is being cop- 

15 jed to the target virtual Track Address. 

[0037] At step 61 0, controller 1 04 determines whether 
the Track Number contained in the selected Virtual 
Track Table entry contains a NULL value. If no data has 
ever been written to the data file described by the se- 

20 iected Virtual Track Table entry or processor 101 has 
instructed data storage subsystem 1 00 to delete the da- 
ta file described by the selected Virtual Track Table en- 
try, the Track Number field in the Virtual Track Table en- 
try will contain a NULL value. If the Track Number stored 

25 in the selected Virtual Track Table entry is found not to 
be a NULL value, processing proceeds with step 611 . 
At step 611, controller 104 decrements the reference 
count in the TNT entry selected by the Track Number 
stored in the selected Virtual Track Table entry. This in- 

30 dicates that there is now one less Virtual Track Address 
by which the data file described by the TNT entry can 
be accessed. If the resulting reference count is zero, it 
indicates that the data file described by the TNT entry 
can no longer be accessed by any Virtual Track Ad- 

6 dress. In this case, the virtual track instance described 
by the TNT entry is no longer needed and the Track 
Number which selects the TNT entry is free to be used 
to describe some new data file to which processor 101 
will assign some other Virtual Track Address. At the 

40 completion of step 61 1 or if the Track Number in the cur- 
rently selected Virtual Track Table entry was found to be 
NULL at step 610, processing proceeds with step 612. 
[0038] At step 612, controller 104 copies the Track 
Number from the Virtual Track Table entry selected by 

45 the source Virtual Track Address to the Virtual Track Ta- 
ble entry selected by the current target Virtual Track Ad- 
dress. This will cause processor 101 reads from either 
the source Virtual Track Address or the Target Virtual 
Address to read the virtual track instance described by 

50 the Track Number which was just copied. 

[0039] At step 613, controller 1 04 determines whether 
the source Track Number which was just copied is a 
NULL value, ff the source Track Number is found not to 
be a Null value, processing proceeds with step 614. At 

55 step 61 4, controller 1 04 increments the reference count 
in the TNT entry selected by the source Track Number. 
This indicates that there is now one more Virtual Track 
Address by which the data file described by the TNT en- 
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try can be accessed. At the completion of Step 61 4 or if 
the source Track Number was found to be NULL at step 
613, processing proceeds with step 615. 
[0040] At step 61 5, controller 1 04 determines whether 
there are additional target tracks within the currently se- 
lected Virtual Track Table Page which have not yet been 
processed. If there is an as yet unprocessed target track 
which selects a Virtual Track Table entry within the cur- 
rent Virtual Track Table Page, processing proceeds with 
step 609. Otherwise, processing proceeds with step 
616. 

[0041 ] At step 61 6, controller 1 04 writes the contents 
of the current Virtual Track Table Page to the backend 
data storage devices 1 05. This creates a new Virtual 
Track Table Page Instance within a Logical Cylinder. 
When writing a Virtual Track Table Page instance to a 
Logical Cylinder, controller 104 also writes a Virtual 
Track Table page instance Logical Cylinder Directory 
Entry to the Logical Cylinder Directory within the Logical 
Cylinder. This Logical Cylinder Directory entry describes 
the Virtual Track Table Page instance stored within the 
Logical Cylinder and contains thesame Logical Cylinder 
Sequence Number which is contained in the Logical cyl- 
inder Directory. The LCSN field of the Virtual Track Table 
Page Instance Logical Cylinder Directory Entry identi- 
fies the Logical cylinder in which the Virtual Track Table 
Page instance was first written so that even if the Virtual 
Track Table Page instance is subsequently moved to a 
different logical cylinder, the mapping table can be re- 
covered by repeating the sequence of mapping table up- 
dates which took place when each logical cylinder was 
written. 

[0042] At step 61 7, controller 1 04 writes into the Log- 
ical Address field of the Virtual Track Table Page within 
the mapping table which was written at step 616 the log- 
ical address at which the Virtual Track Table Page in- 
stance was written at step 616. 
[0043] At step 61 8, controller 1 04 determines whether 
there are additional Virtual Track Table Pages which 
contain entries that are selected by target tracks that 
have not yet been processed. If there is an additional 
Virtual Track Table page containing a Virtual Track Table 
entry which describes an as yet unprocessed target 
track, processing proceeds with step 608. Otherwise, 
processing proceeds with step 619. 
[0044] At step 61 9, controller 1 04 transmits status in- 
formation over data channel 103 indicative of the com- 
pletion of the snapshot copy operation. 
[0045] Figure 7 illustrates in flow diagram form the op- 
erational steps taken by controller 104 to carry out the 
free space collection process which is a part of data file 
management system for snapshot copy operations 1 06. 
The free space collection process moves virtual track 
instances and Virtual Track Table Page instances from 
one logical cylinder to another in order to create com- 
pletely empty logical cylinders into which new virtual 
track instances and Virtual Track Table Page instances 
can be written. When the free space collection process 



encounters a virtual track instance or a Virtual Track Ta- 
ble Page instance, it determines whether controller 1 04 
has written an updated virtual track instance or an up- 
dated Virtual Track Table Page instance to some other 
5 physical location on backend data storage devices 1 05. 
When a more recent instance exists on backend data 
storage devices 105, the free space collection process 
does not copy the now obsolete instance to a different 
logical cylinder. In this way, the free space collection 

10 process discards virtual track instances which are now 
obsolete because processor 101 has updated the data 
file contained within the virtual track instance and con- 
troller 1 04 has written this updated data file to a different 
location in backend data storage devices 1 05. Similarly, 

15 the free space collection process discards Virtual Track 
Table Page instances which are now obsolete because 
a later snapshot copy operation has caused a more re- 
cent instance of the Virtual Track Table Page to be writ- 
ten to a different location in backend data storage de- 

20 vices 1 05. Thus, it is the free space collection process 
which limits the amount of memory contained in back- 
end data storage devices 105 which is consumed hold- 
ing the record of snapshot copy operations. This record 
of snapshot copy operations may be used by controller 

25 104 to allow it to recover the mapping table. The free 
space collection process discards obsolete Virtual Track 
Table page instances, resulting in there being no need 
to store more Virtual Track Table page instances on 
backend data storage devices 1 05 than the number of 

30 Virtual Track Table Pages within the mapping table. 
Without some process for discarding the record of an 
old snapshot copy operation, an unbounded amount of 
memory within backend data storage devices 1 05 would 
be consumed as processor 101 issues an unlimited 

35 number of snapshot copy commands. 

[0046] At step 701 , controller 1 04 selects a logical cyl- 
inder which will have its contents moved to a different 
logical cylinder so that the selected logical cylinder will 
be made empty and available for holding new virtual 

40 track instances and Virtual Track Table Page instances. 
[0047] At step 702, controller 1 04 determines whether 
there is another Logical Cylinder Directory entry in the 
Logical Cylinder Directory for the selected logical cylin- 
der which has not yet been processed. Step 702 is the 

45 first step in a program loop consisting of steps 702 
through 724. Each iteration of this program loop carries 
out the steps required to determine whether the virtual 
track instance or the Virtual Track Table Page instance 
described by the currently selected Logical Cylinder Di- 

50 rectory entry should be moved to another logical cylin- 
der. If the instance should be moved to another logical 
cylinder, the steps within this program loop write the in- 
stance to the other logical cylinder, creating a Logical 
Cylinder Directory entry which will be written tot the oth- 

55 er logical cylinder. If, at step 702, controller 104 deter- 
mines that there are no more Logical Cylinder Directory 
entries in this logical cylinder which have yet to be proc- 
essed, processing proceeds with step 703. Step 703 
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marks the currently selected logical cylinder as being 
empty so that the memory area within data storage de- 
vices 105 which holds the logical cylinder is available 
for being used to store new virtual track instances and 
new Virtual Track Table Page instances. When step 703 5 
completes, processing proceeds with step 701 . 
[0048] If controller 104 determines at step 702 that 
there is an additional Logical Cylinder Directory entry 
within this logical cylinder which is yet to be processed, 
processing proceeds with step 704. At step 704, con- io 
trailer 104 selects the next Logical Cylinder Directory 
entry to be processed. Then at step 705, controller 1 04 
examines the Logical Cylinder Directory Entry Type field 
of the Logical Cylinder Directory entry to determine 
whether the Logical Cylinder Directory entry describes i* 
a virtual track instance or a Virtual Track Table Page in- 
stance. If the Logical Cylinder Directory entry describes 
a virtual track instance, processing proceeds with step 
706. 

[0049] At step 706, controller 104 determines whether 20 
the reference count field of the TNT entry selected by 
the Track Number in the Logical Cylinder Directory entry 
is non-zero. IF the reference count field contains the val- 
ue zero, the virtual track instance described by this Log- 
ical Cylinder Directory entry is no longer needed be- 25 
cause processor 101 has instructed data storage sub- 
system 1 00 to delete the data file contained in the virtual 
track instance selected by the Track Number in the cur- 
rent Logical Cylinder Directory entry. In this case, there 
is no need to preserve the virtual track instance de- 30 
scribed by the current Logical Cylinder Directory entry 
by writing the virtual track instance to another logical cyl- 
inder so processing proceeds with step 702. If controller 
1 04 determines at step 706 that the reference count field 
of the TNT entry selected by the Track Number in the 35 
Logical Cylinder Directory entry in non-zero, processing 
proceeds with step 707. 

[0050] At step 707, controller 1 04 determines whether 
the logical address contained in the TNT entry selected 
by the Track Number in the current Logical Cylinder Di- 40 
rectory entry is equal to the logical address of virtual 
track instance described by the current Logical Cylinder 
Directory entry. If the two logical addresses are not 
equal, the virtual track instance described by the current 
Logical Cylinder Directory entry is obsolete because a 45 
more recent instance of this virtual track is stored at a 
different logical address than the virtual track instance 
described by this Logical Cylinder Directory entry. In this 
case, there is no need to preserve the virtual track in- 
stance describe by the current Logical Cylinder Direc- so 
tory entry by writing the virtual track instance to another 
logical cylinder so processing proceeds with step 702. 
If controller 1 04 determines at step 707 that the two log- 
ical addresses are equal, the virtual track instance de- 
scribed by the current Logical Cylinder Directory entry ss 
is the most recent instance of this virtual track that is 
stored within backend data storage devices 105 and 
processing proceeds with step 708. 



[0051] At step 708, controller 104 determines whether 
the Virtual Track Address field in the current Logical Cyl- 
inder Directory entry contains a NULL value. If the Vir- 
tual Track Address field does not contain a NULL value, 
processing proceeds with step 709 where controller 1 04 
determines whether or not the Track Number in the Vir- 
tual Track Table entry selected by the Virtual Track Ad- 
dress field of the current Logical Cylinder Directory entry 
is equal to the Track Number contained in the current 
Logical Cylinder Directory entry. If the two track num- 
bers are not equal, processor 1 01 has updated the data 
file stored within the virtual track instance but because 
the data file had been copied to another Virtual Track 
Address, a new Track Number was assigned to repre- 
sent the modified data file. In this case, the virtual track 
instance described by the current Logical Cylinder Di- 
rectory entry can no longer be accessed using the Vir- 
tual track Address at which it was originally written by 
processor 1 01 and processing proceeds with step 71 0. 
Also, if controller 104 determines at step 708 that the 
Virtual Track Address in the current Logical Cylinder Di- 
rectory entry already contains a NULL value, processing 
proceeds with step 71 0. 

[0052] At step 71 0, controller 1 04 writes a NULL value 
into the Virtual Track Address field of the new Logical 
Cylinder Directory entry which will describe the current 
virtual track instance when it is written to another logical 
cylinder. 

[0053] If controller 1 04 determines at step 709 that the 
Virtual Track Address in the current Logical Cylinder Di- 
rectory entry is mapped to the same Track Number as 
is stored in the Track Number field of the current Logical 
Cylinder Directory entry, processing proceeds with step 
71 1 . At step 71 1 , controller 1 04 copies the Virtual Track 
Address stored in the current Logical Cylinder Directory 
entry into the new Logical Cylinder Directory entry. 
[0054] After the completion of either step 71 0 or step 
711, processing proceeds with step 712. At step 712, 
controller 104 copies theTrack Number from the current 
Logical Cylinder Directory entry to the new Logical Cyl- 
inder Directory entry. Then, at step 713, controller 1 04 
copies the virtual track instance length from the current 
Logical Cylinder Directory to the new Logical Cylinder 
Directory. 

[0055] At step 714, controller 104 writes to another 
logical cylinder within backend datastorage devices 1 05 
the virtual track instance described by the current Log- 
ical Cylinder Directory entry. At step 715, controller 1 04 
writes into the Logical Address field of the new Logical 
Cylinder Directory entry the logical address at which the 
virtual track instance was written at step 71 4. This com- 
pletes the process of moving the virtual track instance 
described by the current Logical Cylinder Directory entry 
to another logical cylinder. After the completion of step 
717, processing proceeds with step 702. At step 714, 
controller 104 writes to another logical cylinder within 
backend data storage devices 105 the virtual track in- 
stance described by the current Logical Cylinder Direc- 
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tory entry. At step 71 5, controller 1 04 writes into the Log- 
ical Address field of the new Logical Cylinder Directory 
entry the logical address at which the virtual track in- 
stance was written at step 714. At step 716, controller 
1 04 writes the new Logical Cylinder Directory entry into 5 
the Logical Cylinder Directory contained in the logical 
cylinder to which the virtual track instance was written 
at step 714. 

[0056] At step 71 7, controller 1 04 writes into the TNT 
entry selected by the Track Number contained in the cur- 10 
rent Logical Cylinder Directory entry the logical address 
at which the virtual track instance was written at step 
714. This completes the process of moving the virtual 
track instance described by the current Logical Cylinder 
Directory entry to another logical cylinder. After the com- is 
pletion of step 71 7, processing proceeds with step 702. 
[0057] If controller 1 04 determines at step 705 thatthe 
current Logical Cylinder Directory entry describes a Vir- 
tual Track Table Page instance processing proceeds 
with step 71 8. 20 
[0058] At step 718, controller 104 uses the virtual 
Track Table Page Identifier in the current Logical Cylin- 
der Directory entry to select a Virtual Track Table Page 
within the mapping table. Controller 104 then reads the 
Logical Address field from this virtual Track Table page 25 
within the mapping table and compares this logical ad- 
dress to the logical address of the virtual Track Table 
Page instance described by the current Logical Cylinder 
Directory entry. If the two logical addresses are not 
equal, the Virtual Track Table Page instance described 30 
by the current Logical Cylinder Directory entry is obso- 
lete because a later snapshot copy operation caused a 
more recent instance of this Virtual Track Table Page to 
be stored at a different logical address than the Virtual 
Track Table Page instance described by this Logical Cyi- 35 
inder Directory entry. In this case, there is no need to 
preserve the Virtual Track Table Page instance de- 
scribed by the current Logical Cylinder Directory entry 
by writing the Virtual Track Table Page instance to an- 
other logical cylinder so processing proceeds with step 40 
702. If controller 1 04 determines at step 71 8 that the two 
logical addresses are equal, the Virtual Track Table 
Page instance described by the current Logical Cylinder 
Directory entry is the most recent instance of this Virtual 
TrackTable Page that is stored within backend data stor- 
age devices 105 and processing proceeds with step 
719. 

[0059] At step 719, controller 104 copies the Virtual 
Track Table Page identifier stored in the current Logical 
Cylinder Directory entry into the new Logical Cylinder so 
Directory entry which will describe the current virtual 
TrackTable Page instance when it is written to another 
logical cylinder. 

[0060] At step 720, controller 1 04 copies the contents 
of the Original LCSN field from the current Logical Cyi- 55 
inder Directory entry to the new Logical Cylinder Direc- 
tory entry. 

[0061] At step 721 , controller 104 writes to another 



logical cylinder within backend datastorage devices 1 05 
the Virtual Track Table Page instance described by the 
current Logical Cylinder Directory entry. At step 722, 
controller 1 04 writes into the Logical Address field of the 
new Logical Cylinder Directory entry the logical address 
at which the virtual Track Table Page instance was writ- 
ten at step 721 . At step 723, controller 104 writes the 
new Logical Cylinder Directory entry into the Logical 
Cylinder Directory contained in the logical cylinder to 
which the Virtual Track Table Page instance was written 
at step 721. 

[0062] At step 724, controller 1 04 writes into the Log- 
ical Address field of the Virtual Track Table Page within 
the mapping table selected by the virtual Track Table 
Page Identifier field of the current Logical Cylinder Di- 
rectory entry the logical address at which the Virtual 
Track Table Page instance was written at step 721 . This 
completes the process of moving the Virtual Track Table 
Page instance described by the current Logical Cylinder 
Directory entry to another logical cylinder. Afterthe com- 
pletion of step 724, processing proceeds with step 702. 
[0063] The free space collection process is an ongo- 
ing process within data file management system for 
snapshot copy operations 106. The free space collec- 
tion process will pause at step 701 if there are no logical 
cylinders which contain obsolete virtual track instances 
or obsolete Virtual Track Table Page instances or if the 
free space collection process determines that data stor- 
age subsystem 1 00 would not benefit from the immedi- 
ate collection of the free space from an additional logical 
cylinder. The details of this aspect of the behavior of the 
free space collection process are not relevant to the un- 
derstanding of the present invention. 

Virtual Track Management Example 

[0064] Figures 8-13 illustrate, in block diagram form, 
the state of the mapping table and particular logical cyl- 
inders at various stages of a snapshot copy operation, 
which is also illustrated in flow diagram form in Figures 
1 6A - 1 6C. This represents a chronological view of a set 
of virtual tracks and their associated data structures 
from their conception through a number of typical snap- 
shot copy and data storage subsystem 100 operations. 
For the purposes of simplicity of description, the repre- 
sentation for the various entries in the two level mapping 
table and the logical cylinders are simplified to thereby 
illustrate the concepts of the present system and avoid 
the complexity of the implementation details. 
[0065] The virtual track is created within the processor 
101 as part of the processor 101's data management 
function. The processor 101 is connected to and views 
the dynamically mapped virtual data storage subsystem 
100 as a particular size and architecture data storage 
device. Therefore, when the processor 101 wishes to 
store a virtual track instance on the "data storage de- 
vice: embodied by the data storage subsystem 1 00, the 
processor 1 01 formats the virtual track instance and as- 
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signs it a particular virtual track address. The processor 
101 then transmits the virtual track instance and its as- 
sociated virtual track address to the data storage sub- 
system 1 00 at step 1 601 over a selected one of the data 
channels 1 03. In the present example, it is assumed that 5 
the processor 1 01 creates two virtual track instances for 
storage on the data storage subsystem 100. The data 
storage subsystem 1 00, upon receipt of these two virtual 
track instances at step 1602, stores this data in cache 
memory 102 and the controller 1 04 allocates two logical io 
addresses which identify two physical data storage lo- 
cations on the backend data storage devices 1 05 for the 
storage of the two received virtual track instances at 
step 1 603. The controller 1 04 also generates two immu- 
table names for these two virtual track instances at step is 
1604, with the immutable names comprising Track 
Numbers as described above. The controller 1 04 then 
writes the two virtual track instances from the cache 
memory 1 02 to the allocated logical addresses where 
the data is stored at step 1605. The controller 104 at 20 
step 1 605 then updates the two level mapping table to 
reflect the presence of these two virtual track instances 
on the backend data storage devices 1 05. The mapping 
table entries comprise two entries in the Virtual Track 
Table VTT for Device N, Cylinder X, with the first entry 25 
VT#1 having an entry of TN=1 and the second entry 
VT#2 having an entry TN=2. These Track Numbers 
(TN=1 , TN=2) are shortened versions of the actual num- 
bers but serve to illustrate the operation of the mapping 
table. The Track Numbers point to corresponding en- 30 
tries in the Track Number Table TNT, wherein data in- 
dicative of the logical address and reference count for 
the two virtual track instances are stored. The logical 
address data for the first and second virtual track in- 
stances are LA=0.1 .0 and LA=0.1 .1 , respectively, indie- 35 
ative of the physical storage locations of logical device 
0, logical cylinder 1, sectors 0, 1, respectively. Since 
these two virtual track instances are newly crated and 
no other virtual track addresses point to them, the ref- 
erence counts RC are set to 1 to indicate that a single 40 
virtual track address points to the respective virtual track 
instances. Thus, as shown in Figure 8, at the end of time 
period 1, the processor 101 has created two virtual 
tracks, virtual track 1 and virtual track 2, both of which 
are stored in the allocated logical addresses comprising *s 
logical cylinder 1 of logical device 0, sectors 0 and 1. 
The Logical Cylinder Directory LCD for logical cylinder 
1 contains data entries that identify the existence of vir- 
tual tracks 1 , 2. The logical address entry in the Virtual 
Track Table Page contains a NULL value, since no snap- so 
shot copies have been made involving virtual tracks in 
the page. 

[0066] At step 1 607, the processor 1 01 requests the 
creation of a snapshot copy of virtual tracks 1 , 2 and has 
assigned Virtual Track Addresses of N.X.3 and N.X.4 55 
respectively to these two copies of the original virtual 
track instances. The Virtual Track addresses N.X.3 and 
N.X.4 are indicative of virtual device N, cylinder X, tracks 



3, 4, respectively. In response to receipt of commands 
from the processor 1 01 received over a selected data 
channel 103, of step 1608 the data storage subsystem 
1 00 activates the data file storage management system 
for snapshot copy operations 1 06 to create a single copy 
of both virtual tracks. This is accomplished at step 1 609 
by simply creating two duplicative pointers to point to 
the same virtual track instances. The Virtual Track Table 
entries VT#1 , VT#2 are copies to Virtual Track Table en- 
tries VT#3, VT#4, on the same virtual cylinder, respec- 
tively. At the end of time period 2, the reference counts 
RC in the Track Number Table have been incremented 
to 2, to indicate that there are two Virtual Track Table 
entries VT#1 , VT#3, and VT#2, VT#4 pointing to the vir- 
tual track instances V1 , V2 respectively, stored in the 
physical memory. These two virtual track instances are 
identified as V1 , V2 only for the purposes of this illustra- 
tion to allow later instances of the same virtual tracks to 
be identified uniquely. In Its operation, data file storage 
management system for snapshot copy operations 1 06 
does not utilize or store names such as V1 , V2 to unique- 
ly identify particular virtual track instances. Instead, the 
particular virtual track instance which represents the da- 
ta most recently written to a Virtual Track Address is 
identified by the Track Number which points to the virtual 
track instance. The data for mapping a Virtual Track Ad- 
dress to a Track Number is stored in the Virtual Track 
Table entries VT#3, VT#4, with the entries stored therein 
comprising the Track Numbers TN=1 , TN=2 as with the 
entries for the original virtual Track Addresses, since the 
virtual tracks are unmodified. A Virtual Track Table Page 
Logical Cylinder Directory entry is made in the Logical 
Cylinder Directory. This entry in the Logical Cylinder Di- 
rectory contains the identify of the Virtual Track Table 
Page and the Logical Cylinder Sequence Number as- 
signed to the current instance of logical cylinder A. Also, 
the Virtual Track Table Page that contains the virtual 
tracks that were affected by the snapshot copy opera- 
tion is written to the logical cylinder in the same manner 
as virtual track instances. The backup of the Virtual 
Track Table Page contained within logical cylinder A al- 
lows a mapping table recovery process to reconstruct 
the mapping tables without requiring that either the cop- 
ied virtual track instances be rewritten or the complete 
history of all copy operations be maintained on backend 
data storage devices 1 05. The backup of an entire page 
is a fundamental concept in the two level mapping table 
design in that it simplifies the free space collection proc- 
ess by maintaining the snapshot copy history in Virtual 
Track Table Page size units rather than virtual track size 
units. Therefore, only the most recent version of that 
page needs to be maintained on the backend data stor- 
age devices 1 05 even though multiple copies within that 
page may have occurred. 

[0067] At step 1610, the processor 101 updates or 
modified virtual track 1 in cylinder X of device N and the 
modified version of virtual track 1 must now be embod- 
ied in a physical virtual track instance which differs from 
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the original virtual track instance of virtual track 1 to re- 
flect these changes. The data storage subsystem 100 
creates a new virtual track instance at step 1 611 by ap- 
plying the modifications received from processor 1 01 to 
a physical copy of the original virtual track instance V1 , 5 
resulting in a new virtual track instance which, for pur- 
poses for illustrating this example, is identified in Figure 
10 as virtual track instance V4. The data storage sub- 
system 100 writes the modified version of virtual track 
instance V1 , as virtual track instance V4, onto the back- io 
end data storage device location logical device 0, cylin- 
der 2, sector 2 (LA=0.2.2) and must update the mapping 
table to reflect the presence of a new virtual track in- 
stance at step 1612. In particular, the data file storage 
management system for snapshot copy operations 1 05 
generates an immutable name for the new virtual track 
instance with the immutable name comprising a Track 
Number as described above. The data filed storage 
management system for snapshot copy operations 1 06 
then updates the two level mapping table to reflect the 20 
presence of this new virtual track instance on the back- 
end data storage devices 1 05. The mapping table en- 
tries comprise an entry in the Virtual Track Table for vir- 
tual device N, cylinder X, with the first entry VT#1 being 
converted to an entry of TN=3 to reflect the fact that the 25 
current virtual track instance selected by this Virtual 
Track Address is a modified version of the original virtual 
track instance but the original virtual track instance must 
be preserved because it can be accessed by a different 
Virtual Track Address. Virtual track instance V1 no long- 30 
er represents the contents of virtual track 1 with the orig- 
inal data at sector 0 now being pointed to only by the 
Track Number Table entry that is pointed to by the Virtual 
Track Table entry for virtual track 3. At the end of time 
period 3, the reference count in the Track Number Table 35 
entry has been decremented and a new entry (3) has 
been added to theTrack Number Table. The Logical Cyl- 
inder Directory for logical cylinder 2 contains a normal 
virtual track entry for the updated virtual track. 
[0068] At step 1613, the processor 101 requests the 40 
creation of a snapshot copy, with virtual tracks 1 and 2 
being copied to virtual tracks 5 and 6 respectively, of the 
same cylinder. The controller 1 04 responds to receipt of 
this snapshot copy request by creating two new entries 
in the mapping table to reflect the snapshot copy of two 45 
virtual tracks. In particular, the data file storage manage- 
ment system for snapshot copy operations 106 dupli- 
cates the two immutable names that were used for the 
two original virtual track instances at step 1 61 4, with the 
immutable names comprising the two originally created so 
Track Numbers TN=2 and TN=3 as described above. 
The data file management system for snapshot copy 
106 then updates the two level mapping table to reflect 
the association of these new virtual track addresses with 
the already existing virtual track instances at step 1 61 6. 55 
The mapping table entries comprise two entries in the 
Virtual Track Table for device N , cylinder X, with the first 
entry VT#5 being populated with an entry of TN=3 to 



reflect the fact that the data stored at this virtual track 
address is the data which resulted from the modifica- 
tions written to virtual track 1 at step 1610 above and 
the second entry, VT#6 being populated with an entry 
of TN=2 to reflect the fact that this virtual track address 
selects the virtual track instance which was originally 
written to virtual track 2. The reference counts for the 
Track Number Table entries 2 and 3 have been incre- 
mented to RC=3 and RC=2 to reflect the current number 
of Virtual Track Table entries which now point to these 
Track Number Table entries and thence to the virtual 
track instances V4 and V2 which reside on the backend 
data storage devices 1 05. A Virtual Track Table Logical 
Cylinder Directory entry is made in the Logical Cylinder 
Directory which contains the identify of the Virtual Track 
Table Page and the Logical Cylinder Sequence Number 
assigned to the current instance of logical cylinder C. 
The Virtual Track Table Page that contains the virtual 
tracks which were affected by the snapshot copy is writ- 
ten to logical cylinder C. Figure 11 illustrates the state 
of the mapping table at the end of time period 4 at which 
point the data originally written to virtual track 1 at step 
1 601 now exists as a single instance of data addressed 
on ly by virtual track 3 as a conseq uence of the first snap- 
shot copy that was performed in this sequence and the 
subsequent writing of modified data to virtual track 1 . 
[0069] At step 1622, the controller initiates the free 
space collection process which collects logicai cylinders 

1 and A, creating logical cylinder D, which contains all 
of the collected area. Logical cylinder 1 contains Logical 
Cylinder directory entries that define the creation of vir- 
tual track instances V1 and V2 which processor 101 
originally wrote to Virtual Track Addresses N.X.1 and N. 
X.2. Logical cylinder A contains a Logical Cylinder Di- 
rectory entry which describes the Virtual Track Table 
Page that defines the first snapshot copy operation 
which was performed at step 1609. For virtual track en- 
tries, the free space collection process uses the track 
number that is contained within the Logical Cylinder Di- 
rectory entry to index the Track Number Table to deter- 
mine whether the current virtual track instance is the 
most recent. In this case, at the start of time period 5, 
the Track Number Table entries fortrack numbers 1 and 

2 each contain a non-zero reference count and the log- 
ical addresses within each of these two entries in the 
Track Number Table are equal to the logical addresses 
of the virtual track instances V1 and V2 within logical 
cylinder 1 . Therefore, the two virtual track instances V1 
and V2 can each be accessed by one or more Virtual 
Track Addresses and these two virtual track instances 
are still the most recent instances associated with track 
numbers 1 and 2 respectively. The free space collection 
process copies the virtual track instances V1 and V2 
from logical cylinder 1 to logical cylinder D so that logical 
cylinder 1 can be used to hold new virtual track instanc- 
es and Virtual Track Table Page instances. Before writ- 
ing the Logical Cylinder Directory entries describing vir- 
tual track instances V1 and V2 to the Logical Cylinder 
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Directory within logical cylinder D, the free space collec- 
tion process determines whether these virtual track in- 
stances are still selected when processor 1 01 accesses 
the Virtual Track Address at which the virtual, track in- 
stances were originally written. IN the case of virtual 5 
track instance V1 , the free space collection process us- 
es the Virtual Track Address X.N. 1 from the Logical Cyl- 
inder Directory entry for virtual track instance V1 to index 
the Virtual Track Table. This Virtual Track Address se- 
lects Virtual Track Table entry VT#1 which, at step 1 622 10 
contains TN=3. The track number in Virtual Track Table 
entry VT#1 is no longer equal to the track number in the 
Virtual Track Instance Logical Cylinder Directory entry 
for virtual track instance V1 . Therefore, the free space 
collection process writes a NULL value into the Virtual is 
Track Address field of the new Logical Cylinder Direc- 
tory entry for virtual track instance V1 that it writes to 
logical cylinder D. However, in the case of virtual track 
instance V2, the Virtual Track Table entry VT#2 selected 
by virtual Track Address X.N.2 still contains TN=2. 20 
Therefore, the free space collection process copies the 
virtual track address X.N.2 from the Logical Cylinder Di- 
rectory entry for virtual track instance VT2 in logical cyl- 
inder 1 into the new Logical Cylinder Directory entry for 
virtual track instance VT2 in logical cylinder D. The free 25 
space collection process then writes into the Track 
Number Table entries for Track Numbers 1 , 2 the logical 
addresses identifying the physical locations within logi- 
cal cylinder D of virtual track instances V1 , V2, respec- 
tively. 30 
[0070] For Virtual Track Table Page Logical Cylinder 
Directory entries, the free space collection process uses 
the Virtual Track Table Page identifier contained in the 
entry to index into the Virtual Track Table to find the log- 
ical address of the most recent instance of the Virtual 35 
Track Table Page which was written to backend data 
storage devices 1 05. The logical address read from the 
selected Virtual Track Table Page is compared to the 
logical address of the Virtual Track Table Page instance 
described by the virtual Track Table Page Logical Cyl- 40 
inder Directory entry. If the two logical addresses are not 
equal, then the Virtual Track Table Page described by 
the current Logical Cylinder Directory entry is not the 
most recent instance stored on backend data storage 
devices 1 05 and the Virtual Track Table Page instance 45 
described by the current Logical Cylinder Directory entry 
can be discarded. The logical address contained in the 
Virtual Track Table Page identifies a more recent in- 
stance of this Virtual Track Table Page which was written 
to backend data storage devices 1 05 as a consequence so 
of a later snapshot copy operation. Thus, the free space 
collection process does not copy the Virtual Track Table 
Page instance V4 from logical cylinder C to logical cyl- 
inder D. Figure 12 shows the contents of the mapping 
table and the contents of logical cylinder D at the end of 55 
time period 5. 

[0071] At step 1623, the controller 104 initiates the 
free space collection process which collects logical cyl- 



inder C, creating logical cylinder E, which contains all of 
the collected data. Logical Cylinder C contains a Logical 
Cylinder Directory entry which describes the Virtual 
Track Table Page that defines the second snapshot 
copy operation which was performed by steps 1614 and 
1615. The free space collection process uses the Virtual 
Track Table Page identifier contained in the Virtual Track 
Table Page Logical Cylinder Directory entry to index into 
the Virtual Track Table to find the logical address of the 
most recent instance of the virtual Track Table Page 
which was written to backend data storage device 1 05. 
In this case, the logical address stored in the Virtual 
Track Table Page is equal to the logical address of the 
virtual Track Table Page instance described by the Log- 
ical Cylinder Directory in logical cylinder C. This means 
that the Virtual Track Table Page instance is the most 
recent instance of this Virtual Track Table Page stored 
on backend data storage devices 1 05 so the free space 
collection process copies the Virtual Track Table Page 
instance from logical cylinder C to logical cylinder E. In 
the new Virtual Track Table Page Logical Cylinder Di- 
rectory Entry written to logical cylinder E by the free 
space collection process, the Original Logical Cylinder 
Sequence Number field contains a copy of the Original 
Logical Cylinder Sequence Number field from the Log- 
ical Cylinder Directory entry from logical cylinder C. 
Should it become necessary to recover the mapping ta- 
ble using the Logical Cylinder Directory entries, the Vir- 
tual Track Table Page Logical Cylinder Directory entry 
will indicate that the appropriate time to apply the Virtual 
Track Table Page instance which the free space collec- 
tion process copied to logical cylinder E is after applying 
the mapping table updates resulting from the writing of 
logical cylinders with a logical Cylinder Sequence 
Number less than 83 and before applying updates re- 
sulting from logical cylinders with a Logical Cylinder Se- 
quence Number greater than 83. Now that the Virtual 
Track Table Page instance has been copied from logical 
cylinder C to logical cylinder E, the free space collection 
process writes the logical address of the newly written 
Virtual Track Table Page instance into the Virtual Track 
Table Page. 

Maintenance of Point in Time Copy Semantics 

[0072] For a snapshot copy operation to provide point 
in time copy semantics, the data read and write opera- 
tions initiated by processors 101-1 through 101 -K must 
behave as though the data files being copied using the 
snapshot copy method were copied at the instant the 
snapshot copy command is received by data storage 
subsystem 1 00. To provide this behavior, controller 1 04 
within data storage subsystem 1 00 carries out steps to 
ensure that data access operations performed by any 
processor 1 01 are completed before the mapping table 
updates resulting from the snapshot copy operation are 
performed. Steps 601 through 607 in Figure 6 ensure 
that all data written to the copy source area before the 
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initiation of the copy operation will appear in the copy 
target area, all data written to the copy target area before 
the initiation of the copy will be overwritten by data from 
the copy source area and all data being read from the 
target area before the initiation of the copy operation will 5 
not reflect the results of the copy operation. 
[0073] Another aspect of maintaining point in time 
copy semantics is ensuring that no data written to the 
copy source area after the initiation of the copy will ap- 
pear in the copy target area, no data written to the copy io 
target area after the initiation of the copy will be over- 
written by data from the copy source area and all data 
read from the copy target area after the initiation of the 
copy will reflect the completion of the copy operation and 
will not result in reading the data previously stored in the 
target area. Figures 14 and 15 depict the steps per- 
formed by data file management system for snapshot 
copy operations 1 06 within controller 1 04 to achieve this 
second aspect of maintaining point in time copy seman- 
tics. 20 
[0074] Figure 14 illustrates in flow diagram form the 
operational steps taken by controller 1 04 when screen- 
ing data file read requests received from processor 1 01 
by data storage subsystem 1 00. At step 1 401 , controller 
1 04 determines whether the data file read request spec- 25 
ifies a Virtual Track Address which is the target of an in- 
progress snapshot copy operation. If the data file read 
request is for a virtual track which is the target of an in- 
progress snapshot copy operation and the update of the 
Virtual Track Table entry selected by the data file's Vir- 30 
tual Track Address has not yet been performed by the 
snapshot copy process, processing proceeds with step 
1402. 

[0075] At step 1 402, controller 1 04 translates the Vir- 
tual Track Address of the data file wh ich is the target of 35 
the snapshot copy operation to the Virtual Track Ad- 
dress of the data file which is being copied. This trans- 
lated Virtual Track Address is then used for all subse- 
quent operational steps required to complete the proc- 
essor 101 read file request. In this way, data storage 40 
subsystem 100 transfers the copy source data file to 
processor 1 01 in response to the data file read request 
Thus, the data file received by processor 101 in re- 
sponse to a data file read request that is received by 
data storage subsystem 1 00 while a snapshot copy op- 45 
eration is in progress in the same as the data file that 
would have been received by processor 1 01 in response 
to the data file read request had the snapshot copy op- 
eration been performed instantly. 

[0076] Alternatively, if controller 104 determines at so 
step 1401 that either the data file read request is not for 
a copy target data file or the snapshot copy operation 
has already copied the Track Number describing the 
source data file to the Virtual Track Table entry which 
describes the target data file, processing proceeds with ss 
step 1403. The step 1403, processor 104 uses the Vir- 
tual Track Address specified by processor 101 in the 
read file request for all subsequent operational steps re- 



quired to complete the read file request. These subse- 
quent operational steps are the usual steps performed 
by a dynamically mapped virtual storage subsystem. 
[0077] Figure 15 illustrates in flow diagram form the 
operational steps taken by controller 1 04 when screen- 
ing virtual track write requests which are generated by 
data file management system for snapshot copy opera- 
tions 1 06 for the purpose of writing new or modified vir- 
tual tracks to backend data storage devices 1 05. At step 
1501, controller 104 determines whether the virtual 
track is the target of an in-progress snapshot copy op- 
eration and the Virtual Track Table entry selected by the 
Virtual Track Address of the Virtual track being written 
is within a Virtual Track Table Page which the snapshot 
copy operation has not yet written to backend data stor- 
age devices 105. If this is so, processing proceeds with 
step 1502. At step 1502, controller 1 04 delays the writ- 
ing of the virtual track until the in-progress snapshot 
copy operation has written the Virtual Track Table Page 
that contains the Virtual Track Table entry selected by 
the Virtual Track Address assigned by processor 101 
when it wrote or modified the virtual track. This prevents 
any modified data written by processor 101 to the data 
file contained in the virtual track subsequent to the initi- 
ation of the snapshot copy operation from being over- 
written by the data file contained in the source virtual 
track that is being copied. 

[0078] if controller 104 determines at step 1501 that 
the writing of the virtual track did not have to be delayed 
due to the track being the target of an in-progress snap- 
shot copy, processing proceeds with step 1 503. At step 

1503, controller 104 determines whether the virtual 
track is the source of an in-progress snapshot copy op- 
eration and the Virtual Track Table entry selected by the 
Virtual Track Address of the virtual track to which the 
current virtual track is being copied is within a Virtual 
Track Table Page which the snapshot copy operation 
has not yet written to backend data storage devices 1 05. 
If this is so, processing proceeds with step 1 504. At step 

1 504, controller 1 04 delays the writing of the virtual track 
until the in-progress snapshot copy operation has writ- 
ten the Virtual Track Table Page that contains the Virtual 
Track Table entry selected by the Virtual Track Address 
of the virtual track to which the current virtual track is 
being copied. This prevents any modified data written 
by processor 1 01 to the data file contained in the virtual 
track subsequent to the initiation of the snapshot copy 
operation from being copied to the data file which is the 
target of the snapshot copy operation. 

[0079] If controller 1 04 determines at step 1 503 that 
the writing of the virtual track did not have to be delayed 
due to the track being the source of an in-progress snap- 
shot copy, processing proceeds with step 1505. At step 

1505, controller 104 allows the write of the virtual track 
instance to proceed without delay. 
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Summary 

[0080] Thus, the present data file storage manage- 
ment system for snapshot copy operations 1 06 both ef- 
ficiently ensures the reliability of the mapping table data s 
and also performs an incremental copy process which 
preserves the point in time copy semantics to ensure 
copy data file correspondence to the original data file. 
This system maintains a two level mapping table which 
enables the data files to be copied using the snapshot 10 
copy process 107 and only having to update a single 
corresponding mapping table entry when the physical 
location of the data file is changed. In addition, the syn- 
chronization of the snapshot copy operation with the 
reading and writing of data to the original and copy data is 
files is maintained by detecting accesses to the original 
data file or the copy file during the time that the snapshot 
copy process 107 is being executed and the mapping 
table is being updated. 



Claims 

1 . A data file storage management system for use in 

a dynamically mapped virtual data storage subsys- 25 
tern (1 00) to maintain data file copy integrity in snap- 
shot copy operations, wherein said dynamically 
mapped virtual data storage subsystem (1 00) com- 
prises a set of backend data storage devices (1 05) 
for the storage of data files, each having assigned 30 
thereto a virtual track address, received from at 
least one processor (101) which is connected to 
said dynamically mapped virtual data storage sub- 
system (100), said data file storage management 
system comprising: 35 

means for ssigning an immutable identification 
to said data file received from said processor 
(101); 

means for storing data in a first mapping table 40 
to associate said virtual track address assigned 
to said received data file with said assigned im- 
mutable identification; 

means for storing data in a second mapping ta- 
ble to associate said immutable identification to 45 
a logical address indicative of a physical stor- 
age location on one of said backend data stor- 
age devices (105) for the storage of said re- 
ceived data file; and 

means for writing said received data file at said so 
logical address. 

2. The system of claim 1 further comprising: 

means for storing a copy of said first mapping 
table on said backend data storage devices. ss 

3. The system of claim 2 further comprising: 

means, responsive to loss of said first map- 



ping table, for retrieving said copy of said first map- 
ping table from said backend data storage devices. 

4. The system of claim 1 wherein said means for stor- 
ing data in a first mapping table comprises: 

means for storing data indicative of said virtual 
track address assigned to said received data 
file by said processor, and 
means for storing said assigned immutable 
identification in a manner to correspond said 
assigned immutable identification to said virtual 
track address. 

5. The system of claim 4 wherein said means for stor- 
ing data in a second mapping table comprises: 

means for storing said assigned immutable 
identification; 

means for storing data indicative of a number 
of virtual track addresses corresponding to said 
assigned immutable identification; and 
means for storing data indicative of said logical 
address assigned to said stored data file in a 
manner to correspond said assigned immuta- 
ble identification to said logical address. 

6. The system of claim 5 further comprising: 

means, responsive to relocation of said stored 
data file to another logical address in said backend 
data storage devices, for updating said second 
mapping table to reflect location of said stored data 
file at said another logical address, exclusive of up- 
dating said first mapping table. 

7. The system of claim 5 further comprising: 

means, responsive to receipt of a request from 
said processor to copy said received data file 
to a second virtual track address, for assigning 
the immutable identification associated with 
said received data file to said second virtual 
track address; and 

means for activating said means for storing da- 
ta in a second mapping table to store data in 
said second mapping table to associate said 
second immutable identification to said logical 
address indicative of said physical storage lo- 
cation on a one of said backend data storage 
devices which stores said received data file. 

8. The system of claim 7 further comprising: 

means, responsive to said means for storing 
data in a first mapping table storing said data in said 
first mapping table to associate said second virtual 
track address with said immutable identification, for 
incrementing said data indicative of a number of vir- 
tual track addresses corresponding to said as- 
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signed immutable identification. 

9. The system of claim 8 further comprising: 

means, responsive to receipt of a request 
from said processor to modify said received data 5 
file during processing of said request from said 
processor to copy said received data file to a sec- 
ond virtual track address, for delaying storing of the 
modified form of said received data file on said 
backend data storage devices. 10 

10. The system of claim 7 further comprising: 

means, responsive to means for storing data 
in a first mapping table storing said data in said first 
mapping table to associate said second virtual track « 
address with said immutable identification, for stor- 
ing said first mapping table on said backend data 
storage devices. 

1 1 . Tne system of claim 7 further comprising: 20 

means, responsive to means for storing data 
in a first mapping table storing said data in said first 
mapping table to associate said second virtual track 
address with said immutable identification, for stor- 
ing the portion of said first mapping table that con- 25 
tains said stored data on said backend data storage 
devices. 

12. The system of claim 11 further comprising: 

means, responsive to receipt of a request 30 
from said processor to modify said received data 
file during processing of said request from said 
processor to copy said received data file to a sec- 
ond virtual track address, for delaying the storing of 
the modified form of said received data file on said 35 
backend data storage devices until after said mod- 
ified portion of said first mapping table has been 
stored on said backend data storage devices. 

13. The system of claim 1 wherein said means for as- 40 
signing comprises: 

means for maintaining a list of unused immuta- 
ble identifications; 

means, responsive to receipt of a data file hav- 45 
ing a virtual track address from said processor, 
for selecting a one of said unused immutable 
identifications; and 

means for associating said selected unused im- 
mutable identification with said received data so 
file. 

14. A method of data file storage management for use 
in a dynamically mapped virtual data storage sub- 
system (100) to maintain data file copy integrity in 55 
snapshot copy operations, wherein said dynamical- 
ly mapped virtual data storage subsystem (100) 
comprises a set of backend data storage devices 



(105) for the storage of data files, each having as- 
signed thereto a virtual track address, received from 
at least one processor (1 01 ) which is connected to 
said dynamically mapped virtual data storage sub- 
system (100), said data file storage management 
method comprising the steps of: 

assigning an immutable identification to said 
data file received from said processor (101), 
storing data in a first mapping table to associate 
said virtual track address assigned to said re- 
ceived data file with said assigned immutable 
identification; 

storing data in a second mapping table to as- 
sociate said immutable identification to a logi- 
cal address indicative of a physical storage lo- 
cation on one of said backend data storage de- 
vices (1 05) for the storage of said received data 
file; and 

writing said received data file at said logical ad- 
dress. 

15. The method of claim 14 further comprising the step 
of: 

storing a copy of said first mapping table on 
said backend data storage devices. 

16. The method of claim 15 further comprising the step 

of: 

retrieving, in response to loss of said first 
mapping table, said copy of said first mapping table 
from said backend data storage devices. 

17. The method of claim 14 wherein said step of storing 
data in a first mapping table comprises: 

storing data indicative of said virtual track ad- 
dress assigned to said received data file by said 
processor; and 

storing said assigned immutable identification 
in a manner to correspond said assigned im- 
mutable identification to said virtual track ad- 
dress. 

1 8. The method of claim 1 7 wherein said step of storing 
data in a second mapping table comprises: 

storing said assigned immutable identification; 
storing data indicative of a number of virtual 
track addresses corresponding to said as- 
signed immutable identification; and 
storing data indicative of said logical address 
assigned to said stored data file in a manner to 
correspond said assigned immutable identifica- 
tion to said logical address. 

i. The method of daim 1 8 further comprising the step 
of: 
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updating, in response to relocation of said 
stored data file to another logical address in said 
backend data storage devices 105, said second 
mapping table to reflect location of said stored data 
file at said another logical address, exclusive of up- 5 
dating said first mapping table. 

20. The method of claim 1 8 further comprising the steps 
of: 

10 

assigning, in response to receipt of a request 
from said processor to copy said received data 
file to a second virtual track address, the immu- 
table identification associated with said re- 
ceived data file to said second virtual track ad- is 
dress; and 

activating said step of storing data in a second 
mapping table to store data in said second 
mapping table to associate said second immu- 
table identification to said logical address indie- 20 
ative of said physical storage location on a one 
of said backend data storage devices which 
stores said received data file. 

21 . The method of claim 20 further comprising the step 25 
of: 

incrementing, in response to said means for 
storing data in a first mapping table storing said data 
in said first mapping table to associate said second 
virtual track address with said immutable identified- 30 
tion, said data indicative of a number of virtual track 
addresses corresponding to said assigned immuta- 
ble identification. 

22. The method of claim 21 further comprising the step 35 
of: 

delaying, in response to receipt of a request 
from said processor to modify said received data 
file during processing of said request from said 
processor to copy said received data file to a sec- ao 
ond virtual track address, storing of the modified 
form of said received data file on said backend data 
storage devices. 

23. The method of claim 22 further comprising the step 45 
of: 

storing, in response to storing data in a first 
mapping table storing said data in said first mapping 
table to associate said second virtual track address 
with said immutable identification, said first map- so 
ping table on said backend data storage devices. 

24. The method of claim 22 further comprising the step 
of: 

storing, in responsive to storing data in a first ss 
mapping table storing said data in said first mapping 
table to associate said second virtual track address 
with said immutable identification, the portion of 



said first mapping table that contains said stored da- 
ta on said backend data storage devices. 

25. The method of claim 1 1 further comprising the step 
of: 

delaying, in response to receipt of a request 
from said processor to modify said received data 
file during processing of said request from said 
processor to copy said received data file to a sec- 
ond virtual track address, the storing of the modified 
form of said received data file on said backend data 
storage devices until after said modified portion of 
said first mapping table has been stored on said 
backend data storage devices. 

26. The method of claim 1 4 wherein said step of assign- 
ing comprises: 

maintaining a list of unused immutable identifi- 
cations; 

selecting, in response to receipt of a data file 
having a virtual track address from said proc- 
essor, a one of said unused immutable identifi- 
cations; and 

associating said selected unused immutable 
identification with said received data file. 



Patentansp ruche 

1. Datendateispeicher-Managementsystem zur Ver- 
wendung in einem Speicheruntersystem (100) fur 
dynamisch aufgelistete, virtuelle Daten, urn eine 
Datendatei-Kopierintegritat in SchnappschuB-Ko- 
pieroperationen beizubehaften, wobei das Spei- 
cheruntersystem (100) fur dynamisch aufgelistete, 
virtuelle Daten einen Satz von Back-End-Daten- 
speichervorrichtungen (105) fur die Speicherung 
von Datendateien aufweist, wobei jede dazu zuge- 
ordnet eine virtuelle Spur-Adresse besitzt, empfan- 
gen von mindestens einem Prozessor (1 01 ), der mit 
dem Speicheruntersystem (1 00) fur dynamisch auf- 
gelistete, virtuelle Daten verbunden ist, wobei das 
Datendateispeicher-Managementsystem aufweist: 

eine Einrichtung zum Zuordnen einer unveran- 
derbaren Identifikation zu der Datendatei, die 
von dem Prozessor (101) empfangen ist; 
eine Einrichtung zum Speichem von Daten in 
einer ersten Auflistungstabelle, urn die virtuelle 
Spur-Adresse, zugeordnet zu der empfange- 
nen Datendatei, der zugeordneten, unveran- 
derbaren Identifikation zuzuordnen; 
eine Einrichtung zum Speichem von Daten in 
einer zweiten Auflistungstabelle, um die unver- 
anderbare Identifikation zu einer logischen 
Adresse, indikativ fur eine physikalische Spei- 
cherstelle an einer der Back-End-Datenspei- 
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chervorrichtungen (105) fur die Speicherung 
der empfangenen Datendatei, zuzuordnen; 
und 

eine Einrichtung zum Schreiben der empfange- 
nen Datendatei an der logischen Adresse. 

2. System nach Anspruch 1 , das weiterhin aufweist: 
eine Einrichtung zum Speichern einer Kopie der er- 
sten Auflistungstabelle an den Back-End-Daten- 
speichervorrichtungen. 

3. System nach Anspruch 2, das weiterhin aufweist: 
eine Einrichtung, die auf einen Veriust der ersten 
Auflistungstabelle anspricht, urn die Kopie der er- 
sten Auflistungstabelle von den Back-End-Daten- 
speichervorrichtungen autzusuchen. 

4. System nach Anspruch 1, wobei die Einrichtung 
zum Speichern von Daten in einer ersten Aufli- 
stungstabelle aufweist: 

eine Einrichtung zum Speichern von Daten, die 
fur die virtuelle Spur-Adresse, zugeordnet zu 
der empfangenen Datendatei durch den Pro- 
zessor, indikativ sind; und 
eine Einrichtung zum Speichern der zugeord- 
neten, unveranderbaren Identifikation in einer 
Art und Weise, urn der zugeordneten, unveran- 
derbaren Identifikation zu der virtuellen Spur- 
Adresse zu entsprechen. 

5. System nach Anspruch 4, wobei die Einrichtung 
zum Speichern von Daten in einer zweiten Aufli- 
stungstabelle aufweist: 

eine Einrichtung zum Speichern der zugeord- 
neten, unveranderbaren Identifikation; 
eine Einrichtung zum Speichern von Daten, die 
fur eine Anzahl von virtuellen Spur-Adressen 
entsprechend zu der zugeordneten, unveran- 
derbaren Identifikation indikativ sind; und 
eine Einrichtung zum Speichern von Daten, die 
fur die logische Adresse indikativ sind, die zu 
der gespeicherten Datendatei zugeordnet sind, 
in einer Art und Weise, urn der zugeordneten, 
unveranderbaren Identifikation zu der logi- 
schen Adresse zu entsprechen. 

6. System nach Anspruch 5, das weiterhin aufweist: 
eine Einrichtung, die auf eine erneute Zuordnung 
der gespeicherten Datendatei zu einer anderen, lo- 
gischen Adresse in den Back-End-Datenspeicher- 
vorrichtungen anspricht, zum Aktualisieren der 
zweiten Auflistungstabelle, urn eine Stelle der ge- 
speicherten Datendatei an der anderen, logischen 
Adresse, ohne eine Aktualisierung der ersten Auf- 
listungstabelle, zu reflektieren. 



7. System nach Anspruch 5, das weiterhin aufweist: 

eine Einrichtung, die auf einen Empfang einer 
Anforderung von dem Prozessor anspricht, um 

5 die empfangene Datendatei zu einer zweiten, 

virtuellen Spur-Adresse zu kopieren, zum Zu- 
ordnen der unveranderbaren Identifikation, die 
der empfangenen Datendatei zugeordnet ist, 
zu der zweiten, virtuellen Spur-Adresse; und 

io eine Einrichtung zum Aktivieren der Einrich- 

tung zum Speichern von Daten in einer zweiten 
Auflistungstabelle, um Daten in der zweiten 
Auflistungstabelle zu speichern, um die zweite, 
unveranderbare Identifikation zu der logischen 
Adresse, indikativ fur die physikalische Spei- 
cherstelle an einer der Back-End-Datenspei- 
chervorrichtungen, die die empfangene Daten- 
datei speichert, zuzuordnen. 

20 8. System nach Anspruch 7, das weiterhin aufweist: 
eine Einrichtung, die auf die Einrichtung zum Spei- 
chern von Daten in einer ersten Auflistungstabelle, 
die die Daten in der ersten Auflistungstabelle spei- 
chert, anspricht, um die zweite, virtuelle Spur- 
ns Adresse der unveranderbaren Identifikation zuzu- 
ordnen, zum Erhohen der Daten, die fur eine Zahl 
virtueller Spur-Adressen, entsprechend zu der zu- 
geordneten, unveranderbaren Identifikation, indi- 
kativ sind. 

30 

9. System nach Anspruch 8, das weiterhin aufweist: 
eine Einrichtung, die auf einen Empfang einer An- 
forderung von dem Prozessor anspricht, um die 
empfangene Datendatei wahrend einer Verarbei- 

35 tung der Anforderung von dem Prozessor, um die 
empfangene Datendatei zu einer zweiten, virtuellen 
Spur-Adresse zu kopieren, zum Verzogem einer 
Speicherung der modifizierten Form der empfange- 
nen Datendatei an den Back-End-Datenspeicher- 

^0 vorrichtungen, zu modifizieren. 

10. System nach Anspruch 7, das weiterhin aufweist: 
eine Einrichtung, die auf eine Einrichtung zum Spei- 
chern von Daten in einer ersten Auflistungstabelle, 

45 die die Daten in der ersten Auflistungstabelle spei- 
chert, anspricht, um die zweite, virtuelle Spur- 
Adresse mit der unveranderbaren Identifikation, 
zum Speichern der ersten Auflistungstabelle an den 
Back-End-Datenspeichervorrichtungen, zuzuord- 
50 nen. 

11. System nach Anspruch 7, das weiterhin aufweist: 
eine Einrichtung, die auf eine Einrichtung zum Spei- 
chern von Daten in einer ersten Auflistungstabelle, 

55 die die Daten in der ersten Auflistungstabelle spei- 
chert, anspricht, um die zweite, virtuelle Spur- 
Adresse der unveranderbaren Identifikation, zum 
Speichern des Teils der ersten Auflistungstabelle, 
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der die gespeicherten Daten, an den Back-End-Da- 
tenspeichervorrichtungen enthalt, zuzuordnen. 

12. System nach Anspruch 11 , das weiterhin aufweist: 
eine Einrichtung, die auf einen Empfang einer An- 
fordenjng von dem Prozessor anspricht, um die 
empfangene Datendatei wahrend einer Verarbei- 
tung der Anforderung von dem Prozessor zu modi- 
fizieren, um die empfangene Datendatei zu einer 
zweiten, virtuellen Spur-Adresse zu kopieren, zum 
Verzogem der Speicherung in der modifizierten 
Form der empfangenen Datendatei an den Back- 
End-Datenspeichervorrichtungen, bis dann, nach- 
dem der modifizierte Teii der ersten Auflistungsta- 
belle an den Back-End-Datenspeichervomchtun- 
gen gespeichert worden ist. 

13. System nach Anspruch 1, wobei die Einrichtung 
zum Zuordnen aufweist 

eine Einrichtung zum Beibehalten einer Liste 
von nicht verwendeten, unveranderbaren Iden- 
trfikationen, 

eine Einrichtung, die auf einen Empfang einer 
Datendatei, die eine virtuelle Spur-Adresse von 
dem Prozessor besitzt, zum Auswahlen einer 
der nicht benutzten, unveranderbaren Identifi- 
kation, anspricht, und 

eine Einrichtung zum Zuordnen der ausge- 
wahlten, nicht verwendeten, unveranderbaren 
Identifikation zu der empfangenen Datendatei. 

14. Verfahren eines Daten dateispeicher-Manage- 
ments zur Verwendung in einem Speicheruntersy- 
stem (100) furdynamisch aufgelistete, virtuelle Da- 
ten, um eine Datendatei-Kopierintegritat in 
SchnappschuB-Kopieroperationen beizubehalten, 
wobei das Speicheruntersystem (100) fur dyna- 
misch aufgelistete, virtuelle Daten einen Satz von 
Back-End-Datenspeichervorrichtungen (105) fur 
die Speicherung von Datendateien aufweist, wobei 
jede dazu zugeordnet eine virtuelle Spur-Adresse 
besitzt, empfangen von mindestens einem Prozes- 
sor (101), der mit dem Speicheruntersystem (100) 
fur dynamisch aufgelistete, virtuelle Daten verbun- 
den ist, wobei das Datendateispeicher-Manage- 
mentverfahren die Schritte aufweist: 

Zuordnen einer unveranderbaren Identifikation 
zu der Datendatei, die von dem Prozessor 
(101) empfangen ist; 

Speichem von Daten in einer ersten Aufli- 
stungstabelle, um die virtuelle Spur-Adresse, 
zugeordnet zu der empfangenen Datendatei, 
zu derzugeordneten, unveranderbaren Identi- 
fikation zuzuordnen; 

Speichem von Daten in einer zweiten Aufli- 
stungstabelle, um die unveranderbare Identifi- 



kation einer logischen Adresse zuzuordnen, 
die fur eine physikalische Speicherstelle an ei- 
ner der Back-End-Datenspeichervorrich tun gen 
(1 05) indikativ ist, fur die Speicherung der emp- 
5 fangenen Datendatei; und 

Schreiben der empfangenen Datendatei an der 
logischen Adresse. 

15. Verfahren nach Anspruch 14, das weiterhin den 
10 Schritt aufweist: 

Speichem einer Kopie der ersten Auf listungstabelle 
an den Back-End-Datenspeichervorrichtungen. 

16. Verfahren nach Anspruch 15, das weiterhin den 
15 Schritt aufweist: 

Aufsuchen, auf einen Veriust der ersten Auf li- 
stungstabelle hin, der Kopie der ersten Auflistungs- 
tabelle von den Back-End-Datenspeichervomch- 
tungen. 

20 

17. Verfahren nach Anspruch 14, wobei der Schritt ei- 
nes Speichems von Daten in einer ersten Aufli- 
stungstabelle aufweist: 

25 Speichem von Daten, die fur die virtuelle Spur- 

Adresse indikativ sind, zugeordnet zu der emp- 
fangenen Datendatei durch den Prozessor; 
und 

Speichem der zugeordneten, unveranderba- 
30 ren Identifikation in einer Art und Weise, um der 

zugeordneten, unveranderbaren Identifikation, 
zu der virtuellen Spur-Adresse, zu entspre- 
chen. 

35 18. Verfahren nach Anspruch 17, wobei der Schritt ei- 
nes Speichems von Daten in einer zweiten Aufli- 
stungstabelle aufweist: 

Speichem der zugeordneten, unveranderba- 

40 ren Identifikation; 

Speichem von Daten, die fur eine Zahl von vir- 
tuellen Spur-Adressen entsprechend zu derzu- 
geordneten, unveranderbaren Identifikation in- 
dikativ sind; und 

45 Speichem von Daten, die fur die logische 

Adresse, zugeordnet zu der gespeicherten Da- 
tendatei, in einer Art und Weise, um der zuge- 
ordneten, unveranderbaren Identifikation zu 
entsprechen, zu der logischen Adresse, indika- 

50 tivsind. 

19. Verfahren nach Anspruch 18, das weiterhin den 
Schritt aufweist: 

Aktualisieren, in Abhangigkeit einer emeuten Zu- 
55 ordnung der gespeicherten Datendatei zu einer an- 
deren logischen Adresse in den Back-En d-Daten- 
speichervorrichtungen (105), der zweiten Aufll- 
stungstabelle, um eine Stelle der gespeicherten 
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Datendatei an der anderen, logischen Adresse, 
ohne ein Aktualisieren der ersten Auflistungstabel- 
le, zu reflektieren. 

20. Verfahren nach Anspruch 18, das weitertiin die s 
Schritte aufweist: 

Zuordnen, in Abhangigkeit von dem Empfang 
einer Anforderung von dem Prozessor, um die 
empfangene Datendatei zu einer zweiten, vir- 10 
tuellen Adresse zu kopieren, der unverander- 
baren Identif ikation, die der empfangenen Da- 
tendatei zu der zweiten, virtuellen Spur-Adres- 
se zugeordnet ist; und 

Aktivieren des Schritts eines Speicherns von is 
Daten in einer zweiten Auflistungstabelle, um 
Daten in der zweiten Auflistungstabelle zu spei- 
chem, um die zweite, unveranderbare Identifi- 
kation zu der logischen Adresse zuzuordnen, 
die fur die physikalische Speicherstelle an einer 20 
der Back-End-Datenspeichervorrichtungen, 
die die empfangene Datendatei speichert, indi- 
kativ ist. 

21. Verfahren nach Anspruch 20, das weitertiin den 25 
Schritt aufweist: 

Erhohen, in Abhangigkeit von der ersten Einrich- 
tung zum Speichem von Daten in einer ersten Auf- 
listungstabelle, die die Daten in der ersten Aufli- 
stungstabelle speichert, um die zweite, virtuelle 30 
Spur-Adresse zu der unveranderbaren Identifikati- 
on zuzuordnen, der Daten, die fur eine Zahl von vir- 
tuellen Spur-Adressen entsprechend zu der zuge- 
ordneten, unveranderbaren Identifikation Indikativ 
sind. 35 

22. Verfahren nach Anspruch 21 , das werterhin den 
Schritt aufweist: 

Verzogem, in Abhangigkeit eines Empfangs einer 
Anforderung von dem Prozessor, um die empfan- 40 
gene Datendatei wahrend eines Verarbeitens der 
Anforderung von dem Prozessor zu modifizieren, 
um die empfangene Datendatei zu einer zweiten, 
virtuellen Spur-Adresse zu kopieren, eines Spei- 
cherns der modifizierten Form der empfangenen 45 
Datendatei an den Back-End-Datenspeichervor- 
richtungen. 

23. Verfahren nach Anspruch 22, das werterhin den 
Schritt aufweist: so 
Speichem, in Abhangigkeit eines Speicherns von 
Daten in einer ersten Auflistungstabelle, die die Da- 
ten in der ersten Auflistungstabelle speichert, um 

die zweite, virtuelle Spur-Adresse der unverander- 
baren Identifikation zuzuordnen, der ersten Aufli- ss 
stungstabelle an den Back-End-Datenspeichervor- 
richtungen. 



24. Verfahren nach Anspruch 22, das weitertiin den 
Schritt aufweist 

Speichem, in Abhangigkeit eines Speicherns von 
Daten in einer ersten Auflistungstabelle, die die Da- 
ten in der ersten Auflistungstabelle speichert, um 
die zweite, virtuelle Spur-Adresse der unverander- 
baren Identifikation zuzuordnen, des Teils der er- 
sten Auflistungstabelle, der die gespeicherten Da- 
ten, an den Back-End-Datenspeichervorrichtun- 
gen, enthalt. 

25. Verfahren nach Anspruch 11, das weiterhin den 
Schritt aufweist: 

Verzogem, in Abhangigkeit eines Empfangs einer 
Anforderung von dem Prozessor, um die empfan- 
gene Datendatei wahrend eines Verarbeitens der 
Anforderung von dem Prozessor zu modifizieren, 
um die empfangene Datendatei zu einer zweiten, 
virtuellen Spur-Adresse zu kopieren, des Spei- 
cherns der modifizierten Form der empfangenen 
Datendatei an den Back-End-Datenspeichervor- 
richtungen, bis zu einem Zeitpunkt, nachdem der 
modifizierte Teil der ersten Auflistungstabelle an 
den Back-End-Datenspeichervorrichtungen ge- 
speichert worden ist. 

26. Verfahren nach Anspruch 14, wobei der Schritt ei- 
nes Zuordnens aufweist: 

Beibehaften einer Liste von nicht verwendeten, 
unveranderbaren Identifikationen; Auswahlen, 
in Abhangigkeit eines Empfangs einer Daten- 
datei, die eine virtuelle Spur-Adresse besitzt, 
von dem Prozessor, einer der nicht verwende- 
ten, unveranderbaren Identifikationen; und 
Zuordnen der ausgewahlten, nicht verwende- 
ten, unveranderbaren Identifikation zu der 
empfangenen Datendatei. 



Revendications 

1 . Systeme de gestion de stockage de fichier de don- 
nees pour une utilisation dans un sous-systeme de 
stockage de donnees virtuelles cartographies dy- 
namiquement (100) afin de maintenir une integrite 
de copie de fichier de donnees lors ^operations de 
copies instantanees, dans lequel ledit sous-syste- 
me de stockage de donnees virtuelles cartogra- 
phiees dynamiquement (100) comprend un jeu de 
dispositifs de stockage de donnees arrieres (105) 
pour le stockage de f ichiers de donnees dont cha- 
cun se voit assigner une adresse de piste virtuelle, 
recue depuis au moins un processeur (101) qui est 
connects audit sous-systeme de stockage de don- 
nees virtuelles cartographies dynamiquement 
(100), ledit systeme de gestion de stockage de fi- 
chiers de donn6es comprenant : 
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un moyen pour assigner une identification im- 
muable audit f ichier de donnees recu depuis le- 
dit processeur (101) ; 

un moyen pour stocker des donnees dans une 
premiere table de cartographie afin d'associer s 
ladite adresse de piste virtu el le assignee audit 
fichier de donnees recu avec ladite identifica- 
tion immuable assignee ; 
un moyen pour stocker des donnees dans une 
seconde cartographie afin d'associer ladite 10 
identification immuable a une adresse logjque 
qui est indicative d'un emplacement de stocka- 
ge physique sur Tun desdits dispositifs de stoc- 
kage de donnees arrieres (1 05) pour le stocka- 
ge dudit fichier de donnees recu ; et 15 
un moyen pour ecrire ledrt fichier de donnees 
recu a ladite adresse logique. 



faire correspondre ladite identification immua- 
ble assignee a ladite adresse logique. 

6. Systeme selon la revendication 5, comprenant en 
outre : 

un moyen, sensible a une re-localisation dudit 
fichier de donnees stocke" au niveau d'une autre 
adresse logique dans lesdits dispositifs de stocka- 
ge de donnees arrieres, pour mettre a jour ladite 
seconde table de cartographie afin de refleter I'em- 
placement dudit fichier de donnees stock6 au ni- 
veau de ladite autre adresse logique, a {'exclusion 
de la mise a jour de ladite premiere table de carto- 
graphie. 

7. Systeme selon la revendication 5, comprenant en 
outre : 



2. Systeme selon la revendication 1 , comprenant en 
outre : 20 

un moyen pour stocker une copie de ladite 
premiere table de cartographie sur lesdits disposi- 
tifs de stockage de donnees arrieres. 

3. Systeme selon la revendication 2, comprenant en 25 
outre : 

un moyen, sensible a la perte de ladite pre- 
miere table de cartographie, pour retrouver ladite 
copie de ladite premiere table de cartographie a 
partir desdits dispositifs de stockage de donnees 30 
arrieres. 

4. Systeme selon la revendication 1 , dans lequel ledit 
moyen pour stocker des donnees dans une premie- 
re table de cartographie comprend : 35 

un moyen pour stocker des donnees qui sont 
indicatives de ladite adresse de piste virtuelle 
assignee audit fichier de donnees recu par ledit 
processeur ; et 40 
un moyen pour stocker ladite identification im- 
muable assignee de maniere a faire correspon- 
dre ladite identification immuable assignee a la- 
dite adresse de piste virtuelle. 

45 

5. Systeme selon la revendication 4, dans lequel ledit 
moyen pour stocker des donnees dans une secon- 
de table de cartographie comprend : 

un moyen pour stocker ladite identification im- so 
muable assignee ; 

un moyen pour stocker des donnees qui sont 
indicatives d'un nombre d'adresses de pistes 
virtuelles correspondant a ladite identification 
immuable assignee ; et 55 
un moyen pour stocker des donnees qui sont 
indicatives de ladite adresse logique assignee 
audit fichier de donnees stocks de maniere a 



un moyen, sensible a la reception d'une reque- 
te en provenance dudit processeur afin de co- 
pier ledit fichier de donnees recu a une seconde 
adresse de piste virtuelle, pour assigner ('iden- 
tification immuable qui est associee audit fi- 
chier de donnees recu a ladite seconde adres- 
se de piste virtuelle ; et 
un moyen pour activer ledit moyen pour stocker 
les donnees dans une seconde table de carto- 
graphie afin de stocker des donnees dans ladi- 
te seconde table de cartographie afin d'asso- 
cier ladite seconde identification immuable a la- 
dite adresse logique indicative dudit emplace- 
ment de stockage physique sur celui desdits 
dispositifs de stockage de donnees arrieres qui 
stocke ledit fichier de donnees recu. 

8. Systeme selon la revendication 7, comprenant en 
outre : 

un moyen, sensible audit moyen pour stocker 
des donnees dans une premiere table de cartogra- 
phie qui stocke lesdites donnees dans ladite pre- 
miere table de cartographie afin d'associer ladite 
seconde adresse de piste virtuelle avec ladite iden- 
tification immuable, pour incrementer lesdites don- 
nees indicatives d'un nombre d'adresses de pistes 
virtuelles correspondant a ladite identification im- 
muable assignee. 

9. Systeme selon la revendication B, comprenant en 
outre : 

un moyen, sensible a la reception d'une re- 
queue en provenance dudit processeur pour modi- 
fier ledit fichier de donnees recu pendant le traite- 
ment de ladite requete en provenance dudit proces- 
seur afin de copier ledit fichier de donnees recu au 
niveau d'une seconde adresse de piste virtuelle, 
pour retarder le stockage de la forme modif iee dudit 
fichier de donnees recu sur lesdits dispositifs de 
stockage de donnees arrieres. 
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10. Systeme selon la revendication 7, comprenant en 
outre : 

un moyen, sensible au moyen pour stocker 
des donnees dans une premiere table de cartogra- 
phie qui stocke lesdrtes donnees dans ladite pre- s 
miere table de cartographie afin d'associer ladite 
seconde adresse de piste virtuelle a ladite identifi- 
cation immuable, pour stocker ladite premiere table 
de cartographie sur lesdits dispositifs de stockage 
de donnees arrieres. 10 

11. Systeme selon la revendication 7, comprenant en 
outre : 

un moyen, sensible au moyen pour stocker 
des donnees de premiere table de cartographie qui *5 
stocke lesdrtes donnees dans ladite premiere table 
de cartographie afin d'associer ladite seconde 
adresse de piste virtuelle a ladite identification im- 
muable, pour stocker la partie de ladite premiere ta- 
ble de cartographie qui contient lesdites donnees 20 
stock6es sur lesdits dispositifs de stockage de don- 
nees arrieres. 

12. Systeme selon la revendication 11 , comprenant en 
outre : 25 

un moyen, sensible a la reception d'une re- 
queue en provenance dudit processeur pour modi- 
fier ledit fichier de donnees recu pendant le traite- 
ment de ladite requete en provenance dudit proces- 
seur afin de copier ledit fichier de donnees recu au 30 
niveau d'une seconde adresse de piste virtuelle, 
pour retarder le stockage de la forme modif tee dudit 
fichier de donnees recu sur lesdits dispositifs de 
stockage de donnees arrieres jusqu'a apres que la- 
dite partie modifiee de ladite premiere table de car- 35 
tographie a ete stockee sur lesdits dispositifs de 
stockage de donnees arrieres. 

13. Systeme selon la revendication 1 , dans lequel ledit 
moyen d'assignation comprend : 40 

un moyen pour maintenir une liste d'identifica- 
tions immuables inutilisSes ; 
un moyen, sensible a la reception d'un fichier 
de donnees qui presente une adresse de piste 45 
virtuelle en provenance dudit processeur, pour 
sSlectionner Tune desdrtes identifications im- 
muables inutilis§es ; et 

un moyen pour associer ladite identification im- 
muable inutiiisee selectionnee audit fichier de so 
donnees recu. 

14. Proc6d6 de gestion de stockage de fichier de don- 
nees pour une utilisation dans un sous-systeme de 
stockage de donnees virtuelles cartographiees dy- 55 
namiquement (100) afin de maintenir une integrity 

de copie de fichier de donnees lors rf operations de 
copies instantanees, dans lequel ledit sous-syste- 



me de stockage de donnees virtuelles cartogra- 
phiees dynamiquement (100) comprend un jeu de 
dispositifs de stockage de donnees arrieres (105) 
pour le stockage de fichiers de donnees dont cha- 
cun se voit assignor une adresse de piste virtuelle, 
recue depuis au moins un processeur (1 01 ) qui est 
connects audit sous-systeme de stockage de don- 
nees virtuelles cartographies dynamiquement 
(100), ledit proc§d£ de gestion de stockage de fi- 
chier de donnees comprenant les Stapes de : 

assignation d'une identification immuable audit 
fichier de donnees recu depuis ledit processeur 
(101); 

stockage de donnees dans une premiere table 
de cartographie afin d'associer ladite adresse 
de piste virtuelle assignee audit fichier de don- 
nees recu a ladite identification immuable 
assignee ; 

stockage de donnees dans une seconde table 
de cartographie afin d'associer ladite Identifica- 
tion immuable a une adresse logique qui est in- 
dicative d'un emplacement de stockage physi- 
que sur Tun desdits dispositifs de stockage de 
donnees arrieres (105) pour le stockage dudit 
fichier de donnees recu ; et 
ecrfture dudit fichier de donnees recu au niveau 
de ladite adresse logique. 

15. Proc6d§ selon la revendication 14, comprenant en 
outre I'eiape de : 

stockage d'une copie de ladite premiere table 
de cartographie sur lesdits dispositifs de stockage 
de donnSes arrieres. 

16. Proc6d§ selon la revendication 15, comprenant en 
outre I'&ape de : 

recherche, en reponse a la perte de ladite pre- 
miere table de cartographie, de ladite copie de la- 
dite premiere table de cartographie a partir desdits 
dispositifs de stockage de donnees arrieres. 

17. Proc6d§ selon la revendication 14, dans lequel la- 
dite etape de stockage de donnees dans une pre- 
miere table de cartographie comprend ; 

le stockage de donnees qui sont indicatives de 
ladite adresse de piste virtuelle qui est assi- 
gnee audit fichier de donnees recu par ledit 
processeur ; et 

le stockage de ladite identification immuable 
assignee de maniere a faire correspondre ladi- 
te identification immuable assignee a ladite 
adresse de piste virtuelle. 

18. Proc6d6 selon la revendication 17, dans lequel la- 
dite etape de stockage de donnees dans une se- 
conde table de cartographie comprend: 
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le stockage de ladrte identification immuable 
assignee ; 

le stockage de donnees indicatives d'un n om- 
bre d'adresses de pistes virtuelies correspon- 
dant a ladite identification immuable assignee ; 5 
et 

le stockage de donnees qui sont indicatives de 
ladite adresse logique qui est assignee audit fi- 
chier de donnees stocke de maniere a f aire cor- 
responds ladite identification immuable assi- 10 
gnee a ladite adresse logique. 

19. Precede selon la revendication 18, comprenant en 
outre I'etape de : 

mise a jour, en reponse a une re-localisation is 
dudit fichier de donnees stocks au niveau d'une 
autre adresse logique dans lesdits dispositifs de 
stockage de donn6es anieres (105), de ladite se- 
conde table de cartographie afin de ref leter I'emp la- 
cement dudit fichier de donnees stocke au niveau 20 
de ladite autre adresse logique, a I'exclusion de la 
mise a jour de ladite premiere table de cartographie. 

20. Precede selon la revendication 18, comprenant en 
outre les etapes de : 25 

assignation, en reponse a la reception d'une re- 
qudte en provenance dudit processeur pour co- 
pier ledit fichier de donnees recu au niveau 
d'une seconde adresse de piste virtuelle, de 30 
I 'identification immuable qui est associee audit 
fichier de donnees recu a ladite seconde adres- 
se de piste virtuelle ; et 
activation de ladite etape de stockage de don- 
nees dans une seconde table de cartographie 35 
afin de stocker des donnees dans ladite secon- 
de table de cartographie afin d'associer ladite 
seconde identification immuable a ladite adres- 
se logique qui est indicative dudit emplacement 
de stockage physique sur celui desdits dispo- *o 
sitifs de stockage de donnees anieres qui stoc- 
ke ledit fichier de donnees recu. 

21 . Precede selon la revendication 20, comprenant en 
outre I'etape de : 45 

incrementation, en reponse audit moyen pour 
stocker des donnees d'une premiere table de car- 
tographie qui stocke (esdites donnees dans ladite 
premiere table de cartographie afin d'associer ladite 
seconde adresse de piste virtuelle a ladite identifi- so 
cation immuable, desdites donnees qui sont indica- 
tives d'un nombre d'adresses de pistes virtuelies 
correspondant a ladite identification immuable as- 
signee. 

55 

22. Proced6 selon la revendication 21 , comprenant en 
outre a I'etape de : 

retardement, en reponse a la reception d'une 



requeue en provenance dudit processeur pour mo- 
difier ledit fichier de donnees recu pendant le trai- 
tement de ladite requete en provenance dudit pro- 
cesseur afin de copier ledit fichier de donnees recu 
au niveau d'une seconde adresse de piste virtuelle, 
du stockage de la forme modifiee dudit fichier de 
donnees recu sur lesdits dispositifs de stockage de 
donnees anieres. 

23. Precede selon la revendication 22, comprenant en 
outre I'etape de : 

stockage, en reponse au stockage de don- 
nees d'une premiere table de cartographie qui stoc- 
ke (esdites donnees dans ladite premiere table de 
cartographie afin d'associer ladite seconde adresse 
de piste virtuelle a ladite identification immuable, de 
ladite premiere table de cartographie sur lesdits dis- 
positifs de stockage de donnees anieres. 

24. Proced6 selon la revendication 22, comprenant en 
outre I'etape de : 

stockage, en reponse au stockage de don- 
n6es dans une premiere table de cartographie qui 
stocke lesdites donnees dans ladite premiere table 
de cartographie afin d'associer ladite seconde 
adresse de piste virtuelle a ladite identification im- 
muable, de la partie de ladite premiere table de car- 
tographie qui contient lesdites donnees stockees 
sur lesdits dispositifs de stockage de donnees ani- 
eres. 

25. Procede selon la revendication 1 1 , comprenant en 
outre I'etape de : 

retardement, en reponse a la reception d'une 
requdte en provenance dudit processeur pour mo- 
difier ledit fichier de donnees recu pendant le trai- 
tement de ladite requdte en provenance dudit pro- 
cesseur pour copier ledit fichier de don nees recu au 
niveau d'une seconde adresse de piste virtuelle, du 
stockage de la forme modifiee dudit fichier de don- 
nees recu sur lesdits dispositifs de stockage de 
donnees anieres jusqu'a apres que ladite partie 
modifiee de ladite premiere table de cartographie 
ait ete stockee sur lesdits dispositifs de stockage 
de donnees anieres. 

26. Procede selon la revendication 14, dans lequel la- 
dite etape d'assignation comprend : 

le maintien d'une liste ^identifications immua- 
bles inutilisees ; 

la selection, en reponse a la reception d'un fi- 
chier de donnees qui presente une adresse de 
piste virtuelle en provenance dudit processeur, 
d'une desdites identifications immuables et 
inutilisees ; et 

1'association de ladite identification immuable 
inutilisee sdlectionnde avec ledit fichier de don- 
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